NOTICE

Dear Reader:
CableLabs officially closed our Real-time Event Signaling and Management API
specification, OC-SP-ESAM-API-C01-161021.
The Society of Cable Telecommunications Engineers (SCTE ISBE) has since updated
and standardized this specification and related files. They are available here:
http://www.scte.org/SCTE/Standards/SCTE_Standards_Page_3.aspx.
Scroll down that page to:
ANSI/SCTE 250 – Real-time Event Signaling and Management API

The standard is available for download there with the related schema zip file link directly
below the document link.
Questions or issues with those posted files can be sent to: contact SCTE standards

Note: For historical purposes only, this closed specification's content begins on the
following page.
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

OpenCable™ Specifications
Alternate Content

Event Signaling and Management API

OC-SP-ESAM-API-C01-161021
CLOSED

Notice

This OpenCable specification is the result of a cooperative effort

undertaken at the direction of Cable Television Laboratories, Inc. for the
benefit of the cable industry and its customers. This document may
contain references to other documents not owned or controlled by
CableLabs®. Use and understanding of this document may require
access to such other documents. Designing, manufacturing, distributing,
using, selling, or servicing products, or providing services, based on this
document may require intellectual property licenses from third parties
for technology referenced in this document.

Neither CableLabs nor any member company is responsible to any

party for any liability of any nature whatsoever resulting from or arising
out of use or reliance upon this document, or any document referenced
herein. This document is furnished on an "AS IS" basis and neither
CableLabs nor its members provides any representation or warranty,
express or implied, regarding the accuracy, completeness,
noninfringement, or fitness for a particular purpose of this document, or
any document referenced herein.
 Cable Television Laboratories, Inc., 2012-2016

2 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

DISCLAIMER

This document is published by Cable Television Laboratories, Inc. ("CableLabs®").

CableLabs reserves the right to revise this document for any reason including, but not limited to,
changes in laws, regulations, or standards promulgated by various agencies; technological
advances; or changes in equipment design, manufacturing techniques, or operating procedures
described, or referred to, herein. CableLabs makes no representation or warranty, express or
implied, with respect to the completeness, accuracy, or utility of the document or any
information or opinion contained in the report. Any use or reliance on the information or opinion
is at the risk of the user, and CableLabs shall not be liable for any damage or injury incurred by
any person arising out of the completeness, accuracy, or utility of any information or opinion
contained in the document.
This document is not to be construed to suggest that any affiliated company modify or change
any of its products or procedures, nor does this document represent a commitment by CableLabs
or any cable member to purchase any product whether or not it meets the described
characteristics. Nothing contained herein shall be construed to confer any license or right to any
intellectual property, whether or not the use of any information herein necessarily utilizes such
intellectual property. This document is not to be construed as an endorsement of any product or
company or as the adoption or promulgation of any guidelines, standards, or recommendations.

10/21/16 CableLabs 3
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Document Status Sheet

Document Control OC-SP-ESAM-API-C01-161021

Number:

Document Title: Event Signaling and Management API

Revision History: I01 – Released 9/10/12

I02 – Released 10/1/13
I03 – Released 10/25/13
I04 – Released 10/21/16

Date: October 21, 2016

Status: Work in Draft Issued Closed

Progress

Distribution Restrictions: Author Only CL/Member CL/ Public

Member/
Vendor

Key to Document Status Codes

Work in An incomplete document, designed to guide discussion and generate

Progress feedback that may include several alternative requirements for
consideration.

Draft A document in specification format considered largely complete, but

lacking review by Members and vendors. Drafts are susceptible to
substantial change during the review process.
Issued A stable document, which has undergone rigorous member and
vendor review and is suitable for product design and development,
cross-vendor interoperability, and for certification testing.
Closed A static document, reviewed, tested, validated, and closed to further
engineering change requests to the specification through CableLabs.

Trademarks
CableLabs® is a registered trademark of Cable Television Laboratories, Inc. Other CableLabs
marks are listed at http://www.cablelabs.com/certqual/trademarks. All other marks are the
property of their respective owners.

4 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Contents
1 SCOPE................................................................................................................................... 10
1.1 Introduction and Purpose ................................................................................................. 10
1.2 Requirements ................................................................................................................... 13
2 REFERENCES ..................................................................................................................... 15
2.1 Normative References ..................................................................................................... 15
2.2 Informative References.................................................................................................... 16
2.3 Reference Acquisition ..................................................................................................... 16
3 TERMS AND DEFINITIONS............................................................................................. 17
4 ABBREVIATIONS AND ACRONYMS ............................................................................ 18
5 MESSAGE TRANSPORT RECOMMENDED PRACTICE........................................... 19
5.1 Time Synchronization...................................................................................................... 19
6 COMMON CONVENTIONS ............................................................................................. 20
6.1 StatusCode ....................................................................................................................... 20
6.1.1 StatusCode Semantics ............................................................................................... 20
6.2 Date and Time Format (UTCZulu) .................................................................................. 22
6.3 Duration Format (ISODuration) ...................................................................................... 23
6.4 Base64 Binary Format ..................................................................................................... 23
7 COMMON API .................................................................................................................... 24
7.1 Common API Messages .................................................................................................. 24
7.1.1 Control Messages...................................................................................................... 24
7.1.2 General Processing Messages .................................................................................. 52
7.2 Common API Types ........................................................................................................ 73
7.2.1 Address ...................................................................................................................... 73
7.2.2 BatchInfo ................................................................................................................... 76
7.2.3 CallOut...................................................................................................................... 77
7.2.4 SPSCallOuts.............................................................................................................. 79
8 SIGNAL CONFIRMATION AND CONDITIONING API ............................................. 82
8.1 Signal Confirmation Use Cases ....................................................................................... 82
8.1.1 SpliceInsert to Signal Ads ......................................................................................... 82
8.1.2 TimeSignal with SegmentationDescriptor to Signal an Ad....................................... 82
8.1.3 TimeSignal with SegmentationDescriptor to signal a Blackout ............................... 82
8.1.4 Normalize Signal Format.......................................................................................... 83
8.1.5 Out-of-Band Notification of Blackout ....................................................................... 83
8.1.6 Regions Defined Using Signal Metadata .................................................................. 83
8.2 Signal Confirmation and Conditioning API Messages.................................................... 83
8.2.1 SignalProcessingEvent ............................................................................................. 83
8.2.2 SignalProcessingNotification ................................................................................... 89
9 MANIFEST CONFIRMATION AND CONDITIONING API ..................................... 111

10/21/16 CableLabs 5
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

9.1 Manifest Conditioning Use Cases ................................................................................. 111

9.1.1 Smooth conditioning for ads insertion .................................................................... 111
9.1.2 HLS conditioning for ads insertion ......................................................................... 112
9.1.3 Conditioning for blackouts ..................................................................................... 112
9.1.4 Support multi-format conditioning ......................................................................... 112
9.1.5 Support VOD processing ........................................................................................ 112
9.2 Manifest Confirmation and Conditioning API Messages.............................................. 112
9.2.1 ManifestConfirmConditionEvent ............................................................................ 112
9.2.2 ManifestConfirmConditionNotification .................................................................. 116
10 DEPENDANT SCHEMAS AND APIS ......................................................................... 131
10.1 CableLabs MD Signaling Schema ............................................................................. 131
10.1.1 StreamTimes ........................................................................................................ 131
10.2 CableLabs MD Content Schema ................................................................................ 132
11 EXAMPLE SIGNALING DIAGRAMS ....................................................................... 133
11.1 In-band Signaling Example ........................................................................................ 133
11.2 Out-of-band Signaling Example................................................................................. 133
11.3 Out-of-band Manifest Conditioning Example ........................................................... 135
ANNEX A ESAM NORMATIVE SCHEMAS................................................................... 136
A.1 ESAM Common Schema............................................................................................... 136
A.2 ESAM Signal Schema ................................................................................................... 136
A.3 ESAM Manifest Schema ............................................................................................... 136
APPENDIX I ACKNOWLEDGEMENTS........................................................................... 137
APPENDIX II REVISION HISTORY ................................................................................. 138

Figures
Figure 1 - Sample Control System Implementation ..................................................................... 10
Figure 2 - Example of Real-time IP Video Application ............................................................... 12
Figure 3 - Example of File-based IP Video Application (transcoder initiated) ............................ 12
Figure 4 - Example of File-based IP Video Application (POIS Initiated) .................................... 13
Figure 5 - StatusCode XML Schema ............................................................................................ 20
Figure 6 - Summary of Control Interfaces .................................................................................... 25
Figure 7 - SASRegistrationRequest XML Schema ...................................................................... 27
Figure 8 - SASRegistrationResponse XML Schema .................................................................... 32
Figure 9 - SPSRegistrationRequest XML Schema ....................................................................... 36
Figure 10 - SPSRegistrationResponse XML Schema................................................................... 39
Figure 11 - SASDeregistrationRequest XML Schema ................................................................. 41
Figure 12 - SASDeregistrationResponse XML Schema............................................................... 43
Figure 13 - SPSDeregistrationRequest XML Schema .................................................................. 45

6 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 14 - SPSDeregistrationResponse XML Schema ............................................................... 47

Figure 15 - ServiceCheckRequest XML Schema ......................................................................... 49
Figure 16 - ServiceStatusNotification XML Schema ................................................................... 51
Figure 17 - Mode 1 Message Exchange ........................................................................................ 53
Figure 18 - Mode 2 Message Exchange ........................................................................................ 53
Figure 19 - ProcessStatusNotification XML Schema ................................................................... 55
Figure 20 - ProcessStatusAcknowledgement XML Schema ........................................................ 62
Figure 21 - ProcessStatusRequest XML Schema ......................................................................... 64
Figure 22 - ProcessStatusResponse XML Schema ....................................................................... 66
Figure 23 - SignalStateRequest XML Schema ............................................................................. 69
Figure 24 - UriProcessingRequest XML Schema ......................................................................... 72
Figure 25 - Address Element XML Schema ................................................................................. 74
Figure 26 - BatchInfoType XML Schema .................................................................................... 77
Figure 27 - CallOutType XML Schema ....................................................................................... 79
Figure 28 - SPSCallOutsType XML Schema ............................................................................... 81
Figure 29 - SignalProcessingEvent XML Schema ....................................................................... 84
Figure 30 - AcquiredSignal XML Schema ................................................................................... 85
Figure 31 - SignalProcessingNotification XML Schema ............................................................. 91
Figure 32 - ConditioningInfo XML Schema ................................................................................ 92
Figure 33 - ResponseSignal XML Schema ................................................................................... 93
Figure 34 - AlternateContent XML Schema ................................................................................. 94
Figure 35 - EventSchedule XML Schema .................................................................................... 94
Figure 36 - ThirdPartTag XML Schema ....................................................................................... 95
Figure 37 - ManifestConfirmConditionEvent XML Schema ..................................................... 112
Figure 38 - AcquiredSignal XML Schema ................................................................................. 113
Figure 39 - ManifestConfirmConditionNotification XML Schema ........................................... 116
Figure 40 - ManifestResponse XML Schema ............................................................................. 117
Figure 41 - SegmentModify XML Schema ................................................................................ 118
Figure 42 - SegmentReplace XML Schema ............................................................................... 118
Figure 43 - SparseTrack XML Schema ...................................................................................... 119
Figure 44 - SpliceCueInfo XML Schema ................................................................................... 119
Figure 45 - TemplateResponse XML Schema ............................................................................ 120
Figure 46 - StreamTime XML Schema ...................................................................................... 131
Figure 47 - In-band Signaling Example ...................................................................................... 133
Figure 48 - Out-of-band Signaling Example .............................................................................. 134
Figure 49 - Out-of-band Manifest Conditioning Example ......................................................... 135

10/21/16 CableLabs 7
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Tables
Table 1 - StatusCode Semantic Attributes .................................................................................... 20
Table 2 - StatusCode Semantics Elements.................................................................................... 21
Table 3 - classCode Attribute Values ........................................................................................... 21
Table 4 - detailCode Attribute Values .......................................................................................... 21
Table 5 - SASRegistrationRequest Attributes .............................................................................. 27
Table 6 - SASRegistrationRequest Elements ............................................................................... 28
Table 7 - Message Values ............................................................................................................. 28
Table 8 - AttributeName Values ................................................................................................... 29
Table 9 - SASRegistrationResponse Elements and Attributes ..................................................... 32
Table 10 - SPSRegistrationRequest Elements and Attributes ...................................................... 36
Table 11 - SPSRegistrationResponse Elements and Attributes .................................................... 39
Table 12 - SASDeregistrationRequest Elements and Attributes .................................................. 41
Table 13 - SASDeregistrationResponse Elements and Attributes ................................................ 43
Table 14 - SPSDeregistrationRequest Elements and Attributes ................................................... 45
Table 15 - SPSDeregistrationResponse Elements and Attributes................................................. 47
Table 16 - ServiceCheckRequest Elements and Attributes .......................................................... 49
Table 17 - ServiceStatusNotification Elements and Attributes .................................................... 51
Table 18 - ProcessStatusNotification Elements and Attributes .................................................... 56
Table 19 - ProcessStatusAcknowledgement Attributes ................................................................ 62
Table 20 - ProcessStatusRequest Attributes ................................................................................. 64
Table 21 - ProcessStatusResponse Attribute ................................................................................ 66
Table 22 - SignalStateRequest Attributes ..................................................................................... 70
Table 23 - UriProcessingRequest Attributes................................................................................. 73
Table 24 - Address ........................................................................................................................ 74
Table 25 - Address Formats .......................................................................................................... 74
Table 26 - BatchInfo ..................................................................................................................... 76
Table 27 - CableLabs content:MovieType Usage ........................................................................ 76
Table 28 - CallOut ........................................................................................................................ 78
Table 29 - SPSCallOuts ................................................................................................................ 79
Table 30 - Message Values ........................................................................................................... 80
Table 31 - AttributeName Values ................................................................................................. 80
Table 32 - AcquiredSignal Attributes ........................................................................................... 86
Table 33 - AcquiredSignal Elements ............................................................................................ 86
Table 34 - SignalProcessingNotification Attributes and Elements............................................... 95
Table 35 - ResponseSignal Attributes........................................................................................... 96
Table 36 - ResponseSignal Elements ............................................................................................ 97

8 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Table 37 - AlternateContent Attributes......................................................................................... 97

Table 38 - ConditioningInfo Attributes ........................................................................................ 98
Table 39 - ConditioningInfo Elements ......................................................................................... 98
Table 40 - Segment Attribute........................................................................................................ 99
Table 41 - EventScheduleType Attributes .................................................................................... 99
Table 42 - EventScheduleType Elements ..................................................................................... 99
Table 43 - ThirdPartyTag Attributes............................................................................................. 99
Table 44 - ManifestConfirmConditionNotification Elements .................................................... 120
Table 45 - ManifestConfirmConditionNotification Attributes ................................................... 120
Table 46 - ManifestResponse Attributes..................................................................................... 121
Table 47 - ManifestResponse Elements ...................................................................................... 122
Table 48 - SegmentModify Elements ......................................................................................... 123
Table 49 - SegmentReplace Elements ........................................................................................ 123
Table 50 - Segment Attributes .................................................................................................... 124
Table 51 - Segment Elements ..................................................................................................... 124
Table 52 - SparseTrack Attributes .............................................................................................. 124
Table 53 - Template Response Attributes ................................................................................... 124
Table 54 - TemplateType Attribute Values ................................................................................ 125
Table 55 - TemplateType for Segmentation Types .................................................................... 125
Table 56 - Manifest Line Substitution Keywords ....................................................................... 127
Table 57 - Tag Attributes ............................................................................................................ 127
Table 58 - locality Attribute........................................................................................................ 128
Table 59 - StreamTime Type Semantics Attributes .................................................................... 131
Table 60 - timeType Attribute Values ........................................................................................ 132
Table 61 - timeValue Formats .................................................................................................... 132

10/21/16 CableLabs 9
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

1 SCOPE
1.1 Introduction and Purpose

This document details the interfaces between a Signal Acquisition System (SAS) and a Signal
Processing System (SPS) in order to support signal and manifest processing. The APIs support
system element controls, synchronous signal processing, asynchronous signal processing, and
processing of URI based content (ex. file reference).
The control interfaces support:
SAS registration/deregistration
SPS registration/deregistration
Service status check
Service status notification
Figure 1 shows a representative implementation that includes a signal acquisition system and a
signal processing system. The signal processing system is composed of a control element and a
redundant set of signal processing elements.

SAS Config
(out of scope)

5. SPS Call outs

Signal Acquisition System

2. SAS Call outs

1. Registration Request 4. Registration Request

W-SAS W-SPS
Call outs and attributes Call outs and attributes

6. Registration
3. Registration
Response
Response

Control Processing Processing

Element Element Element

Signal Processing Subsystem

Signal Processing Instructions

(ex. SCTE 224 ESNI)
(out of scope of this specification)

Figure 1 - Sample Control System Implementation

10 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

1. An SAS registers (#1) with the SPS Control Element. The SAS registration message
includes the callouts (#2) and attributes.
2. The SPS responds to the registration (#3).
3. Once an SAS registers with the SPS, the SPS registers (#4) with the SPS. The SPS
registration message included the callouts (#5) and attributes. This particular
implementation includes 2 signal processing elements that the SAS would call when a
signal is received. Both of these signal processing elements are supplied in the list of
callouts. For a fully redundant implementation configuration, an SAS SHOULD call both
signal processing elements to make sure it receives a response.
4. The SAS responds to the registration (#6).
5. Assuming there is a service check callout specified in #2 or #5, the SAS and/or SPS
would periodically check in with the other end point.
Section 7.1.1 for further discussion of the control messages.
In addition to interfaces to support control of system elements, this document defines two
interfaces that are used either for signal processing and stream conditioning or for manifest
conditioning.
The first interface allows a Signal Acquisition System (e.g., encoder, transcoder, fragmenter,
etc.) to submit signals to a Signal Processing System and receive stream conditioning data and
directives (Section 8); while the second interface allows submission of a confirmed signal and
receipt of manifest manipulation instructions (Section 9) to a Signal Acquisition System. A given
implementation may be comprised of one or more Signal Acquisition Systems.
For example, a real-time transcoder acting as a signal acquisition system submits an SCTE 35
splice insert message to a Placement Opportunity Information System (POIS) acting as a Signal
Processing System. The POIS confirms the validity of the signal and returns information
allowing a transcoder to identify and update the start or end times of a signal region. The call
also may return relevant information such as signal region duration(s) that could be used for
conditioning the stream being encoded. The returned information may additionally include
auxiliary data to be inserted into the video stream for downstream systems, which could consume
the auxiliary data and process according to specific application requirements.

10/21/16 CableLabs 11
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 2 - Example of Real-time IP Video Application

Furthermore, in an Adaptive Bitrate (ABR) packaging application, the ABR fragmenter also
submits the previously confirmed signal to the POIS. In return, manifest-specific conditioning
instructions could be provided, which the fragmenter inserts on behalf of the end-to-end system.
For URI based content, a transcoder can operate in one of two operational modes. In the first
mode, the transcoder calls the POIS to obtain the signal regions for content in a file. Figure 3
illustrates this model.
Example of URI based Video Application
Transcoder Initiated

File Based
Or
URI Origin CDN
Source
Reference
Conditioned
Content

Intermediate
File Based
Initiate
Control Point Transcoder Or Fragmeter
Process
URI
Destination

URI Request
Manifest Conf. and
With
Conditioning
Signal Processing Notification
SCTE 35
NPT

CableLabs 3.0
Metadata
W-Signal Metadata POIS Security

Figure 3 - Example of File-based IP Video Application (transcoder initiated)

12 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

In the second mode, the transcoder is directed to process the file-based content based on
directives in the request. Figure 4 illustrates this model.
Example of URI based Video Application
POIS Initiated

File Based
Or
URI Origin CDN
Source
Reference
Conditioned
Content

Intermediate
File Based
Transcoder Or Fragmeter
URI
Destination

Manifest Conf. and

Signal Processing Notification
Conditioning
NPT
SCTE 35

CableLabs 3.0
Metadata
W-Signal Metadata POIS Security

Initiate
Process

Control Point

Figure 4 - Example of File-based IP Video Application (POIS Initiated)

To fully understand the ABR conditioning portions of this document, the reader is expected to be
familiar with and understand the different ABR delivery formats and their individual
terminology.
The Event Signaling and Management API supports both JSON and XML event and notification
message payload formats with the caller controlling the payload format using standard HTTP
semantics. This specification leverages the CableLabs Metadata 3.0 signaling schema.

1.2 Requirements

Throughout this document, the words that are used to define the significance of particular
requirements are capitalized. These words are:

"SHALL" This word means that the item is an absolute requirement of this
specification.

"SHALL This phrase means that the item is an absolute prohibition of this
NOT" specification.

"SHOULD" This word means that there may exist valid reasons in particular
circumstances to ignore this item, but the full implications should be
understood and the case carefully weighed before choosing a different
course.

10/21/16 CableLabs 13
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

"SHOULD This phrase means that there may exist valid reasons in particular
NOT" circumstances when the listed behavior is acceptable or even useful, but
the full implications should be understood and the case carefully weighed
before implementing any behavior described with this label.

"MAY" This word means that this item is truly optional. One vendor may choose
to include the item because a particular marketplace requires it or
because it enhances the product, for example; another vendor may omit
the same item.

14 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

2 REFERENCES
2.1 Normative References

In order to claim compliance with this specification, it is necessary to conform to the following
standards and other works as indicated, in addition to the other requirements of this specification.
Notwithstanding, intellectual property rights may be required to use or implement such
normative references.
All references are subject to revision, and parties to agreement based on this specification are
encouraged to investigate the possibility of applying the most recent editions of the documents
listed below.

[CEP 3.0] Content Encoding Profiles 3.0 Specification, OC-SP-CEP3.0-I05-151104,

November 4, 2015, Cable Television Laboratories, Inc.
[CONTENT 3.0] CableLabs Metadata 3.0 Specification, MD-SP-CONTENTv3.0-C01-
151104, November 4, 2015, Cable Television Laboratories, Inc.
[ID-HLS] Internet Draft, HTTP Live Streaming, https://tools.ietf.org/html/draft-pantos-
http-live-streaming-20 Expires: March 24, 2017.
[ISO 8601] ISO 8601:2004, Data elements and interchange formats -- Information
interchange -- Representation of dates and times (Coordinated Universal
Time).
[F4M] Flash® Media Manifest (F4M) Format Specification Version 3.0 FINAL,
http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/hds/pdfs/adobe-
media-manifest-specification.pdf
[JSON] JavaScript Object Notation (JSON), http://www.json.org.
[RFC 2616] IETF RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J.
Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June
1999.
[RFC 4648] IETF RFC 4648, The Base16, Base32, and Base64 Data Encodings. S.
Josefsson. October 2006.
[SCTE 35] ANSI/SCTE 35 2016, Digital Program Insertion Cueing Message for Cable.
[SCTE 172] ANSI/SCTE 172 2011 Constraints on AVC Video Coding for Digital
Program Insertion.

10/21/16 CableLabs 15
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

2.2 Informative References

This specification uses the following informative references.

[SCTE 67] ANSI/SCTE 67 2014, Recommended Practice for SCTE 35 Digital

Program Insertion Cueing Message for Cable.
[SCTE 224] SCTE 224 2015 Event Scheduling and Notification Interface (ESNI).

2.3 Reference Acquisition

• Cable Television Laboratories, Inc., 858 Coal Creek Circle, Louisville, CO 80027;
Phone +1-303-661-9100; Fax +1-303-661-9199; http://www.cablelabs.com
• Internet Engineering Task Force (IETF), Internet: http://www.ietf.org/
Note: Internet-Drafts are draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time.
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
Internet-Drafts may also be accessed at http://tools.ietf.org/html/
• SCTE, Society of Cable Telecommunications Engineers, Inc., 140 Philips Road, Exton, PA
19341 Phone: +1-800-542-5040, Fax: +1-610-363-5898, Internet: http://www.scte.org
• International Organization for Standardization, ISO Central Secretariat, Chemin de
Blandonnet 8, CP 401, 1214 Vernier, Geneva, Switzerland, www.iso.org

16 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

3 TERMS AND DEFINITIONS

This specification uses the following terms:
Base64 Binary Binary contents coded in Base64 format.
Fragment Small content chunk (typically two seconds of video).
Fragmenter Also referred to as packager or encapsulator.
Media Segment The media segment is the M3U8 extended recorded commencing with
the #EXTINF tag through to its paired URI line inclusive of any line in
between that starts with #EXT.
Segment An MPEG-2 Transport Stream divided into a series of small media
files typically of equal duration (for example ten seconds).
Signal Point A particular point of interest within a video essence.
Signal Region A region of interest within a video essence.

10/21/16 CableLabs 17
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

4 ABBREVIATIONS AND ACRONYMS

This specification uses the following abbreviations:
ABR Adaptive Bitrate
API Application Programming Interface
DASH MPEG Dynamic Adaptive Streaming over HTTP
GUID Globally Unique Identifier
HDS HTTP Dynamic Streaming (Adobe Zeri)
HLS HTTP Live Streaming (Apple)
HSS HTTP Smooth Streaming (Microsoft Smooth)
HTTP Hypertext Transfer Protocol
JSON JavaScript Object Notation
LAN Local Area Network
NTP Network Time Protocol
POIS Placement Opportunity Information System
SAS Signal Acquisition System
SPS Signal Processing System
URI Uniform Resource Identifier
UTC Coordinated Universal Time
VOD Video on Demand
WAN Wide Area Network
XML Extensible Markup Language

18 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

5 MESSAGE TRANSPORT RECOMMENDED PRACTICE

The signal processing services are exposed as an HTTP RESTful endpoint. Each API has a
unique URI and both the event payload and the notification payload SHALL support XML
objects and MAY support JSON. HTTP POST is the required request method. The request
message's HTTP Accept header is set to the value "application/json" or "application/xml" for the
application's desired return data format.
The server SHALL return a valid HTTP [RFC 2616] status code indicating the result of the
message exchange and application processing. For application processing errors, the HTTP
payload SHALL contain additional information in the StatusCode element, as detailed in Section
6.1.
System to system communications are considered to be in a trusted environment; therefore,
security-related concerns are currently outside the scope of this specification. Further, systems
MAY experience communications failures, and it is left to the implementer to devise the best
messaging resiliency and timeout tactics to meet specific customer needs. It is suggested the
implementer provide configurations around potential retries in the event synchronous
notifications are not received, as well as configurations around what behavior would be expected
in such cases. For example, one might provide a default permissive configuration in the event a
notification is not received: the signaled event is allowed to pass. Another MAY take the same
behavior but also retry multiple times on some interval. Another MAY take a more restrictive
default approach where it is not allowed to pass if a timeout or ambiguous error occurs. All of
these are valid and will depend on the needs and characteristics of the environment. It is
therefore strongly suggested that implementations allow for default behavior to be configurable.

5.1 Time Synchronization

It is expected that time synchronization with multiple high accuracy sources will be maintained
by all components of the systems. Protocols such as NTP allow time synchronization in the sub-
millisecond on LANs and up to a few milliseconds on WANs.

10/21/16 CableLabs 19
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

6 COMMON CONVENTIONS
Note 1: Unless noted as optional, all attributes, elements, and objects are required.
Note 2: In all cases, unrecognized attributes, elements, and objects are to be ignored.

As a convention used throughout this API, a JSON array is identified using a plural name like
'spots' or 'segments'. The XML equivalent utilizes an XML element sequence with a singular
element tag that is capitalized., for example, 'Spot' or 'Segment'. In documentation situations
herein where duplicating the element name is redundant or confusing, the XML value is utilized
and the JSON equivalent is to be assumed by the reader.

6.1 StatusCode

The StatusCode object provides return status information to the caller and is returned for all
application-level errors. The StatusCode object MAY optionally be included in a response
payload to provide warning or informational details in addition to the typically expected payload.
The StatusCode element has the following XML schema:

Figure 5 - StatusCode XML Schema

6.1.1 StatusCode Semantics

Table 1 - StatusCode Semantic Attributes

Name Required Description

classCode Y One of the values from Table 3 as a string.
detailCode O Optional value as a string with a specific code relative to
the classCode. If the classCode is set to error, the detail
code SHOULD be present. If the classCode is a success,
the detailCode MAY NOT be present.
Table 4 enumerates the defined values for detailCode.

20 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Table 2 - StatusCode Semantics Elements

Name Required Description

Note O Optional sequence of descriptive strings. Typically, the
Note element(s) provides descriptive text such as human
readable error messages.

Table 3 - classCode Attribute Values

Value Description
0 Success
1 Error
2 Warning
3 Information

Table 4 - detailCode Attribute Values

Value Description Notes

0 Reserved
1 General error
2 Resource not found
3 Missing mandatory input
parameter
4 Busy The responding end point SHALL NOT return
an identity and other information in a Notes
Element. (ex. SPS SPSFooBar is busy.)
Remedial action is to retry the request.
5 Shutting down Indicates an end point is shutting down.
6 Restarting Indicates an end point is restarting.
7 Token mismatch Indicates a token in a request did not match
the value from the last registration message.
Remedial action is to re-register the end
points.
8 No compatible address/type Indicates a registration cannot be completed.
A notes element SHALL NOT provide details
on what is supported by the end point.
9 API not supported Indicates a given API is not supported by a
given end point.

10/21/16 CableLabs 21
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Value Description Notes

10 Alternate signal applied In the case where two or more
(redundancy) SignalProcessingEvent messages (See section
8.2.1) are sent by an SAS, the SAS
implementation MAY only apply one of the
responses received, this detail code SHALL
NOT be sent with a status code of 0 (zero).
The response MAY include information about
the response message actually applied. The
following notes element SHOULD be used to
communicate the actual SPS identity and
signal point identity.

<core:Note>applied:signalPointID="fro
m
ResponseSignal",signalProcessingIdent
ity="from
SignalProcessingNotification"</core:N
ote>

This use case also applies to asynchronous

SignalProcessingEvent messages. (See section
7.1.2.1.2.4 for an example of usage.)

6.2 Date and Time Format (UTCZulu)

Object time values SHALL follow the [ISO 8601] extended time format of [hh]:[mm]:[ss] except
the StreamTime object values which are in their native time formats. The following list describes
the extended time formats:
[hh] — Zero-padded hour between 00 and 24 (where 24 is only used to notate midnight at the
end of a calendar day).
[mm] — Minute between 00 and 59.
[ss] — Second between 00 and 60 (where 60 is only used to notate an added leap second).
Decimal fractions MAY be added to the seconds component using a decimal point as a separator
between the time element and its fraction. The number of decimal places for the decimal fraction
SHALL be limited to three places for ISO 8601 times.
Combined date and time objects SHALL use the UTC format, and all times SHALL be provided
as zero UTC offset or Zulu times, referred to herein as UTCZulu. Thus, all combined date and
time objects SHALL be formatted as:
2001-12-17T11:12:42.123Z

22 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

6.3 Duration Format (ISODuration)

Duration values, referred to as ISODuration herein, SHALL follow the [ISO 8601] format as
well and are represented by the format P[n]Y[n]M[n]DT[n]H[n]M[n]S. In these representations,
the [n] is replaced by the value for each of the date and time elements that follow the [n].
Leading zeroes MAY be included, if applicable. The capital letters P, Y, M, W, D, T, H, M, and S
are designators for each of the date and time elements and are not replaced.
The following list describes the date and time elements:
P — Duration designator placed at the start of the duration representation.
Y — Year designator that follows the value for the number of years.
M — Month designator that follows the value for the number of months.
W — Week designator that follows the value for the number of weeks.
D — Day designator that follows the value for the number of days.
T — Time designator that precedes the time components of the representation.
H — Hour designator that follows the value for the number of hours.
M — Minute designator that follows the value for the number of minutes.
S — Second designator that follows the value for the number of seconds.
For example, "P3Y6M4DT12H30M5S" represents a duration of three years, six months, four
days, twelve hours, thirty minutes, and five seconds. Date and time elements including their
designator MAY be omitted if their value is zero, and lower order elements MAY also be
omitted for reduced precision. For example, "P23DT23H" and "P4Y" are both acceptable
duration representations.
To resolve ambiguity, "P1M" is a one-month duration and "PT1M" is a one-minute duration
(note the time designator, T, that precedes the time value). Seconds MAY have a decimal
fraction specified with a period as "PT30.5S", which is an example of 30 and one-half seconds.
The duration value SHALL be formatted using the canonical form where each field does not
exceed the field's standard maximum value. The second and minute values SHALL be less than
60, and the hours field SHALL be less than 24. For example, 90-seconds is to be formatted as
PT1M30S and not as PT90S.

6.4 Base64 Binary Format

Binary contents SHALL be coded in Base64 format per section 6.8 of [RFC 4648] with W3C
recommendations.

10/21/16 CableLabs 23
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

7 COMMON API
The Common API is a set of messages used for both Signal Confirmation and Conditioning (see
Section 8) and Manifest Confirmation and Conditioning (see Section 9) to support synchronous
and asynchronous processing of signals and manifests. The Common APIs include control, URI
based content (ex. a VOD asset file), status information, and other common messages.

7.1 Common API Messages

The Common API messages support both control (see section 7.1.1) and general purpose
processing (see section 7.1.2) messages exchanged between SAS and SPS system elements.
Signal (see section 8) and Manifest (see section 9) define additional processing messages.

7.1.1 Control Messages

As described earlier, the control interfaces support:
SAS registration/deregistration
SPS registration/deregistration
Service status check
Service status notification
Figure 6 lists the messages supported.

24 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Signal Acquisition System

Signal Processing System Config System
(ex . Encoder, Transcoder, Packager, etc.)

Config data to SAS

(ex. SPS registration details)
SASRegistrationRequest (out of scope of specification)
(SAS Call outs, attributes, w-token (opt))

SASRegistrationResponse The SASRegistrationResponse may include

(Success/Failure w-optional SPS info) SPS information.

SPSRegistrationRequest
(SPS Call outs, attributes w-token (opt)) After doing initial registration with an SAS, if
SPS attributes or callouts change, an SPS may
SPSRegistrationResponse resend an SPS RegistrationRequest to an SAS
Success or failure to update information.

SASDeregistrationRequest

SASDeregistrationResponse

SPSDeregistrationRequest

SPSDeregistrationResponse

ServiceCheckRequest Service check request can also be used in the

opposite direction.
. A ServiceStatusNotification
may be sent in response to a
ServiceStatusNotification ServiceCheckRequest or asynchronously to
notify the end point of a change in status.
.

Figure 6 - Summary of Control Interfaces

In one workflow an SAS is configured with the SPS to register with. How an SAS is configured
is out of scope of this specification.
1. An SAS registers with an SPS. The message includes callouts and attributes. The SAS
may also pass a token that will be used on all subsequent messages exchanged between
an SAS and an SPS. Use of tokens is highly recommended as they serve to verify the
state of each end point.
The SPS response to a registration may include SPS registration information as described
in 2. If an implementation chooses to send SPS information in the SAS registration
response message as defined in 2 above, the service checks will be important to verify
proper setup of system elements.
2. Once an SAS registers the SPS can then register with the SAS if not already done in the
SAS registration response. The message includes callouts and attributes. The SPS may
also pass a token that will be used on all subsequent messages exchanged between an
SAS and an SPS. Use of tokens is highly recommended as they serve to verify the state of
each end point. The SPS Registration message can be resent to an SAS to update the
registration information.

10/21/16 CableLabs 25
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

3. On a periodic bases the end points can send service check messages to verify the
connection with a given end point. The service check can be done form the SAS to the
SPS and/or from the SPS to the SAS.
4. A service status notification is sent by an end point asynchronously if some specific
status event needs to be communicated.
5. The SAS or SPS can deregister to allow for orderly shutdown of the connection.

7.1.1.1 SASRegistrationRequest
The SASRegistrationRequest message is used to register an SAS with an SPS. In addition to
identity information about the SAS, specific call outs and attributes about the SAS are passed in
the message.
If the sasToken attribute is passed in the registration message, it SHALL be used on all
subsequent message exchanges that originate from an SAS to an SPS. If a given SAS, uniquely
identified by a given acquisitionPointIdentity, sends a new registration request with a new
sasToken prior to deregistering, the previous registration SHALL be canceled and any in process
activities will be considered terminated by the SAS. In the absence of specific language in this
specification, the specific disposition of any in process activities SHALL be considered out of
scope of this specification.
The SASRegistrationRequest MAY include information if one SAS system is registering as a
replacement for another SAS system.
The SPS is expected to respond with an SASRegistrationResponse. (See section 0)

26 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

The following XML payload is passed:

Figure 7 - SASRegistrationRequest XML Schema

7.1.1.1.1 SASRegistrationRequest Semantics

Table 5 - SASRegistrationRequest Attributes

Name Required Description

acquisitionPointIdentity Y The identification of the SAS registering SHALL be
specified. The acquisitionPointIdentity SHALL be
unique across all SAS entities that will be registering

10/21/16 CableLabs 27
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Name Required Description

with a given SAS.
sasToken O Optional token that uniquely identifies this registration.
replacingAcquisitionPointId C If the registering SAS is replacing another SAS system,
entity the identification of the SAS being replaced SHALL be
specified.
replacingSasToken C If an SAS is being replaced and an SAS token was
passed in the registration message, the SAS token of
the SAS system being replaced SHALL be specified.

Table 6 - SASRegistrationRequest Elements

Name Required Description

SASCallout O Optional list of CallOuts associated with the SAS registering. The
message types supported are listed in Table 7. See Section 7.2.3
for additional detail on specifying call outs.
SASAttribute O Optional list of attributes associated with the SAS registering. See
Table 8 for the list of Attribute values defined by this
specification.

Table 7 - Message Values

Schema Message Reference

Common ProcessStatusRequest See section 7.1.2.3.
Common ServiceCheckRequest See section 7.1.1.9
Common ServiceStatusNotification See section 7.1.1.10
Common SPSRegistrationRequest See section 7.1.1.3
Common SPSDeregistrationRequest See section 7.1.1.7
Common URIProcessingRequest If URI push request is supported. See
section 7.1.2.6
Manifest ManifestConfirmConditionNotification See section 9.2.2
Signal SignalProcessingNotification See section 8.2.2

28 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Table 8 - AttributeName Values

attributeName Type Description

ServiceCheckInterval Duration If ServiceCheckRequest is specified, the time interval
between service checks. (ex. PT0.500S)
StreamIdentifier String An identity of the stream being processed by the
SAS. The identity SHALL NOT be fully qualified.
(Ex. The HGTV EIDIR video service id MAY be
expressed as urn:doi:10.5239:8C19-C863)
PRIVATE:.. Various Additional private AttributeName values MAY be
defined for a specific implementation. Such private
values SHALL be prefaced with “PRIVATE:”

7.1.1.1.2 SASRegistrationRequest Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns:common="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

7.1.1.1.2.1 SASRegistrationRequest Example 1

The following is a comprehensive example illustrating how an SAS “AcquisitionPointFooBar”,
signal or manifest, can register with an SPS. This request includes an sasToken that SHALL
NOT be utilized on all subsequent message exchanges with the SAS. Section 7.2.1 describes
how to define address information.
<common:SASRegistrationRequest
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A"
acquisitionPointIdentity="AcquisitionPointFooBar">
<!-- SASRegistrationRequest - sent from SAS to SPS to identify the end
points for the SAS -->
<!-- *** ESAM common messages - works for both ESAM Signal and/or ESAM
Manifest compliant systems *** -->
<common:SASCallout message="ProcessStatusRequest">
<common:Address type="type0">Address0</common:Address>
</common:SASCallout>
<common:SASCallout message="ServiceCheckRequest">
<common:Address type="type0">Address0</common:Address>
</common:SASCallout>
<common:SASCallout message="ServiceStatusNotification">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<common:SASCallout message="SPSRegistrationRequest">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<common:SASCallout message="SPSDeregistrationRequest">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<!-- if URI push request is supported -->
<common:SASCallout message="URIProcessingRequest">
<common:Address type="type2">Address2</common:Address>

10/21/16 CableLabs 29
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

</common:SASCallout>
<!-- *** ESAM manifest messages *** -->
<common:SASCallout message="ManifestConfirmConditionNotification">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<!-- *** ESAM signal messages *** -->
<common:SASCallout message="SignalProcessingNotification">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<!-- Call out for all messages go to same end point -->
<common:SASCallout message="All">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<!-- not all attributes apply in all cases -->
<common:SASAttribute
attributeName="ServiceCheckInterval">PT60S</common:SASAttribute>
<common:SASAttribute
attributeName="StreamIdentifier">urn:eidr:10.5239:ED6E-
0DBB</common:SASAttribute>
</common:SASAttribute>
</common:SASRegistrationRequest>

7.1.1.1.2.2 SASRegistrationRequest – SAS replacement

The following is an example illustrating how an SAS “AcquisitionPointNew”, signal or manifest,
can register with an SPS as a replacement for “AcquisitionPointOld”. This request includes an
SAS tokens for both the old and new end points. This message indicates to the SPS that the old
end point SHALL NOT be considered active. This message can be used when an SAS control
system determines an SAS end point has failed and needs to be replaced with a new SAS end
point instance. Section 7.2.1 describes how to define address information.
<common:SASRegistrationRequest
<!-- SASRegistrationRequest - sent from SAS to SPS to identify the end points
for the SAS - this registration
indicates another SAS is being replaced -->
<!-- *** ESAM common messages - works for both ESAM Signal and/or ESAM
Manifest compliant systems *** -->
<common:SASCallout message="ProcessStatusRequest">
<common:Address type="type0">Address0</common:Address>
</common:SASCallout>
<common:SASCallout message="ServiceCheckRequest">
<common:Address type="type0">Address0</common:Address>
</common:SASCallout>
<common:SASCallout message="ServiceStatusNotification">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<common:SASCallout message="SPSRegistrationRequest">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<common:SASCallout message="SPSDeregistrationRequest">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<!-- if URI push request is supported -->
<common:SASCallout message="URIProcessingRequest">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>

30 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

<!-- *** ESAM manifest messages *** -->

<common:SASCallout message="ManifestConfirmConditionNotification">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<!-- *** ESAM signal messages *** -->
<common:SASCallout message="SignalProcessingNotification">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<!-- Call out for all messages go to same end point -->
<common:SASCallout message="All">
<common:Address type="type2">Address2</common:Address>
</common:SASCallout>
<!-- not all attributes apply in all cases -->
<common:SASAttribute
attributeName="ServiceCheckInterval">PT60S</common:SASAttribute>
<common:SASAttribute
attributeName="StreamIdentifier">urn:eidr:10.5239:ED6E-
0DBB</common:SASAttribute>
<common:SASAttribute
attributeName="StreamIdentifier">urn:merlin:linear:stream:6711010143940900163
</common:SASAttribute>
</common:SASRegistrationRequest>

7.1.1.2 SASRegistrationResponse
The SASRegistrationResponse message is sent by the SPS in response to an
SASRegistrationRequest.
If an sasToken attribute is present in the registration message, the SPS SHALL return the value
in the response. The SPS SHALL retain the sasToken to verify the integrity of subsequent
messages from a given SAS identified by the acquisitionPointIdentity attribute.
The SPS SHALL validate the information passed in the registration message:
Invalid data (ex. unknown callout)
No callout can be supported (ex. incompatible address type)
If the registration cannot be successfully processed the StatusCode SHALL be populated in the
response message. The StatusCode MAY be populated if the registration message is successfully
processed.
The SPS MAY return SPS end point information in the response message in the
SPSEndPointInfo Element.
The following XML payload is passed:

10/21/16 CableLabs 31
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 8 - SASRegistrationResponse XML Schema

7.1.1.2.1 SASRegistrationResponse Elements and Attributes

Table 9 - SASRegistrationResponse Elements and Attributes

Name Required Description

sasToken O Optional token that uniquely identifies the SAS registration.
If it is passed in the registration message it SHALL be passed
in the response. In the case of an SAS replacement
registration this SHALL be the SAS token for the new SAS
end point.
StatusCode O StatusCode SHALL be populated if there is an error while
processing a registration request message. StatusCode MAY
be populated if the registration message is successfully
processed.

32 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Name Required Description

classCode Y Set to 0 (zero) on success. Set to 1 (one) on error.
detailCode O See Section 6.1 for applicable detail codes.
Notes O Populate with additional details related to the StatusCode.
SPSEndPointInfo O The SPS MAY choose to return SPS end point information in
this message. The SPS MAY use the SPS registration
message as an alternate approach. See section 7.1.1.3. The
SPS registration message MAY also be used to update the
SPS end point information.
signalProcessingIden Y The identification of the SPS SHALL be specified. The
tity signalProcessingIdentity SHALL be unique across all SPS
entities that an SAS will register with.
spsToken O Optional token that uniquely identifies the SPS end point. If it
is passed in this message it SHALL be passed in the
response.
SPSCallOuts Y The callouts for 1 or more SPS end points SHALL be
specified. See section 7.2.4.

7.1.1.2.2 SASRegistrationResponse Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns:common="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

7.1.1.2.2.1 SASRegistrationResponse Success

The following response communicates a successful registration.
<common:SASRegistrationResponse
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
<common:StatusCode classCode="0">
</common:StatusCode>
</common:SASRegistrationResponse>

7.1.1.2.2.2 SASRegistrationResponse – w-SPS End Points

The following response communicated successful registration along with the SPS end point
information.
<common:SASRegistrationResponse
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
<common:StatusCode classCode="0"> </common:StatusCode>
<!-- SPS information returned on SAS registration - the spsToken applied
to all SPS end points defined -->
<common:SPSEndPointInfo signalProcessingIdentity="SPSSytemFooBar"
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C">
<common:SPSCallouts spsEndPointName="SPSControlPoint">
<common:SPSCallout message="ProcessStatusNotification">

10/21/16 CableLabs 33
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

<common:Address type="type4">Address4</common:Address>
<common:Address type="type5">Address5</common:Address>
</common:SPSCallout>
<common:SPSCallout message="SASDeregistrationNotification">
<common:Address type="type4">Address4</common:Address>
<common:Address type="type5">Address5</common:Address>
</common:SPSCallout>
<common:SPSCallout message="ServiceCheckRequest">
<common:Address type="type0">Address0</common:Address>
</common:SPSCallout>
<common:SPSCallout message="ServiceStatusNotification">
<common:Address type="type2">Address2</common:Address>
</common:SPSCallout>
<common:SPSCallout message="SignalStateRequest">
<common:Address type="type2">Address2</common:Address>
</common:SPSCallout>
<common:SPSAttribute
attributeName="ServiceCheckInterval">PT5S</common:SPSAttribute>
</common:SPSCallouts>
<common:SPSCallouts spsEndPointName="SPSEndPoint1">
<common:SPSCallout message="ServiceCheckRequest">
<common:Address type="type0">Address0</common:Address>
</common:SPSCallout>
<!-- *** ESAM signal messages *** -->
<common:SPSCallout message="SignalProcessingEvent">
<common:Address type="type0">Address0</common:Address>
<common:Address type="type1">Address1</common:Address>
</common:SPSCallout>
<!-- SignalProcessNotification applicable to batch processing -
provide NPT feedback -->
<common:SPSCallout message="SignalProcessNotification">
<common:Address type="type0">Address0</common:Address>
<common:Address type="type1">Address1</common:Address>
</common:SPSCallout>
<!-- *** ESAM manifest messages *** -->
<common:SPSCallout message="ManifestConfirmConditionEvent">
<common:Address type="type0">Address0</common:Address>
<common:Address type="type1">Address1</common:Address>
</common:SPSCallout>
<common:SPSAttribute
attributeName="ServiceCheckInterval">PT0.005S</common:SPSAttribute>
</common:SPSCallouts>
<common:SPSCallouts spsEndPointName="SPSEndPoint2">
<common:SPSCallout message="ServiceCheckRequest">
<common:Address type="type0">Address0</common:Address>
</common:SPSCallout>
<common:SPSCallout message="SignalProcessingEvent">
<common:Address type="type4">Address4</common:Address>
<common:Address type="type5">Address5</common:Address>
</common:SPSCallout>
<common:SPSCallout message="ManifestConfirmConditionEvent">
<common:Address type="type0">Address0</common:Address>
<common:Address type="type1">Address1</common:Address>
</common:SPSCallout>
<common:SPSAttribute
attributeName="ServiceCheckInterval">PT60S</common:SPSAttribute>
<common:SPSAttribute

34 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

attributeName="SPNTimeOut">PT0.005S</common:SPSAttribute>
</common:SPSCallouts>
</common:SPSEndPointInfo>
</common:SASRegistrationResponse>

7.1.1.2.2.3 SASRegistrationResponse – SPS Busy

If the SPS busy or shutting down it will return the following.
<common:SASRegistrationResponse xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:common="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:cablelabs:iptvservices:esam:xsd:common:1
file:/Users/wmiche00/Documents/16.xxxx%20ESAM%20misc/151229%20Schemas%20for%2
0EC/OC-SP-ESAM-API-I03-Common.xsd"
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
<common:StatusCode classCode="1" detailCode="4">
<core:Note> SPS SPSFooBar is busy.</core:Note>
</common:StatusCode>
</common:SASRegistrationResponse>

7.1.1.2.2.4 SASRegistrationResponse – API not supported

If the SPS does not support a given API it will return the following. The note element identifies
the end point and the specific API. One or more note elements SHALL NOT be provided for
each unsupported end point.
<common:SASRegistrationResponse
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
<common:StatusCode classCode="1" detailCode="9">
<core:Note> AcquisitionPointFooBar - URIProcessingRequest not
supported.</core:Note>
</common:StatusCode>
</common:SASRegistrationResponse>

7.1.1.3 SPSRegistrationRequest
The SPSRegistrationRequest message is used by the SPS to register with an SAS that has
previously registered with the SPS. In addition to identity information about the SPS, specific
call outs and attributes about the SPS are passed in the response message.
If the SAS passed an sasToken attribute in the registration message, the SPS SHALL return the
value in the response. The SPS SHALL retain the sasToken to verify the integrity of subsequent
messages from a given SAS identified by the acquisitionPointIdentity attribute.
If the spsToken attribute is passed in the response message, it SHALL be used on all subsequent
message exchanges that originate from an SPS to an SAS.
The following XML payload is passed:

10/21/16 CableLabs 35
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 9 - SPSRegistrationRequest XML Schema

7.1.1.3.1 SPSRegistrationRequest Elements and Attributes.

Table 10 - SPSRegistrationRequest Elements and Attributes

Name Required Description

signalProcessingIden Y The identification of the SPS registering SHALL be
tity specified. The signalProcessingIdentity SHALL be unique
across all SPS entities that an SAS will register with.
spsToken O Optional token that uniquely identifies this response. If the
spsToken is passed, the SPS SHALL pass the same token on
all messages it sends to an SAS.
sasToken O Optional token that uniquely identifies the SAS end point. If
it is passed in the SAS registration message it SHOULD be
passed in the response.
SPSCallouts O An SPSCallouts Element SHALL be specified for each SPS
end point. See section 7.2.4.

36 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

7.1.1.3.2 SPSRegistrationRequest Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

7.1.1.3.2.1 SPSRegistrationRequest Sample 1

The following is a comprehensive example illustrating how an SPS sub-system can register with
an SAS. This request includes an sasToken from an SASRegistrationRequest and an spsToken
that SHALL NOT be utilized on all subsequent message exchanges with the SPS from the SAS.
Section 7.2.1 describes how to define address information.
In this example there are 3 SPS end points registered:
SPSControlPoint support common messages used by an SAS
SPSEndPoint1 and SPSEndPoint2 provide 2 interfaces an SAS SHALL NOT call for
processing events. In a highly redundant configuration an SAS would call both SPS end
points to make sure that every signal received by an SAS is processed in a reliable/timely
fashion. Due to the importance of handling every signal, this is a recommended mode of
operation.
In this registration messages ServiceCheckRequest messages are specified for all end points.
These ServiceCheckRequest messages allow the SPS to verify the health of every connection
between the end points.
<common:SPSRegistrationRequest signalProcessingIdentity="SPSControlPoint"
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C"
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
<common:SPSCallouts spsEndPointName="SPSControlPoint">
<common:SPSCallout message="ProcessStatusNotification">
<common:Address type="type4">Address4</common:Address>
<common:Address type="type5">Address5</common:Address>
</common:SPSCallout>
<common:SPSCallout message="SASDeregistrationNotification">
<common:Address type="type4">Address4</common:Address>
<common:Address type="type5">Address5</common:Address>
</common:SPSCallout>
<common:SPSCallout message="ServiceCheckRequest">
<common:Address type="type0">Address0</common:Address>
</common:SPSCallout>
<common:SPSCallout message="ServiceStatusNotification">
<common:Address type="type2">Address2</common:Address>
</common:SPSCallout>
<common:SPSCallout message="SignalStateRequest">
<common:Address type="type2">Address2</common:Address>
</common:SPSCallout>
<common:SPSAttribute
attributeName="ServiceCheckInterval">PT5S</common:SPSAttribute>
</common:SPSCallouts>

10/21/16 CableLabs 37
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

<common:SPSCallouts spsEndPointName="SPSEndPoint1">
<common:SPSCallout message="ServiceCheckRequest">
<common:Address type="type0">Address0</common:Address>
</common:SPSCallout>
<!-- *** ESAM signal messages *** -->
<common:SPSCallout message="SignalProcessingEvent">
<common:Address type="type0">Address0</common:Address>
<common:Address type="type1">Address1</common:Address>
</common:SPSCallout>
<!-- SignalProcessNotification applicable to batch processing -
provide NPT feedback -->
<common:SPSCallout message="SignalProcessNotification">
<common:Address type="type0">Address0</common:Address>
<common:Address type="type1">Address1</common:Address>
</common:SPSCallout>
<!-- *** ESAM manifest messages *** -->
<common:SPSCallout message="ManifestConfirmConditionEvent">
<common:Address type="type0">Address0</common:Address>
<common:Address type="type1">Address1</common:Address>
</common:SPSCallout>
<common:SPSAttribute
attributeName="ServiceCheckInterval">PT0.005S</common:SPSAttribute>
</common:SPSCallouts>
<common:SPSCallouts spsEndPointName="SPSEndPoint2">
<common:SPSCallout message="ServiceCheckRequest">
<common:Address type="type0">Address0</common:Address>
</common:SPSCallout>
<common:SPSCallout message="SignalProcessingEvent">
<common:Address type="type4">Address4</common:Address>
<common:Address type="type5">Address5</common:Address>
</common:SPSCallout>
<common:SPSCallout message="ManifestConfirmConditionEvent">
<common:Address type="type0">Address0</common:Address>
<common:Address type="type1">Address1</common:Address>
</common:SPSCallout>
<common:SPSAttribute
attributeName="ServiceCheckInterval">PT60S</common:SPSAttribute>
<common:SPSAttribute
attributeName="SPNTimeOut">PT0.005S</common:SPSAttribute>
</common:SPSCallouts>
</common:SPSRegistrationRequest>

7.1.1.4 SPSRegistrationResponse
The SPSRegistrationResponse message is sent by the SAS in response to an
SPSRegistrationRequest.
If an spsToken attribute is present in the registration message, the SAS SHALL return the value
in the response. The SAS SHALL retain the spsToken to verify the integrity of subsequent
messages from a given SPS identified by the signalProcessingIdentity attribute.
The SAS SHALL validate the information passed in the registration message:
Invalid data (ex. unknown callout)
No callout can be supported (ex. incompatible address type)

38 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

If the registration cannot be successfully processed the StatusCode SHALL be populated in the
response message. The StatusCode MAY be populated if the registration message is successfully
processed. See section 6.1.
The following XML payload is passed:

Figure 10 - SPSRegistrationResponse XML Schema

7.1.1.4.1 SPSRegistrationResponse Semantics

Table 11 - SPSRegistrationResponse Elements and Attributes

Name Required Description

spsToken O If present in the SPS registration messages, it SHALL be passed
in the response message from the SAS.
sasToken O If present in the SAS registration messages, it SHALL be passed
in the response message from the SAS.

10/21/16 CableLabs 39
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Name Required Description

StatusCode O StatusCode SHALL be populated if there is an error while
processing a registration request message. StatusCode MAY be
populated if the registration message is successfully processed.
classCode Y Set to 0 (zero) on success. Set to 1 (one) on error.
detailCode O See Table 4.
Notes O Populate with additional details related to the StatusCode.

7.1.1.4.2 SPSRegistrationResponse Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

7.1.1.4.2.1 SPSRegistrationresponseExample – success

The following response indicates successful registration.
<common:SPSRegistrationResponse
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C"
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
<common:StatusCode classCode="0">
</common:StatusCode>
</common:SPSRegistrationResponse>

7.1.1.5 SASDeregistrationRequest
The SASDeregistrationRequest message used by the SAS to deregister from an SPS that was
previously registered with. If a token was passed on the initial registration message, the same
token SHALL be passed in the deregistration message.

40 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

The following XML payload is passed:

Figure 11 - SASDeregistrationRequest XML Schema

7.1.1.5.1 SASDeregistrationRequest Semantics

Table 12 - SASDeregistrationRequest Elements and Attributes

Name Required Description

acquisitionPointIdentity Y The identification of the SAS end point deregistering
SHALL be specified.
sasToken C If present in the SAS registration messages, it SHALL be
passed in the deregistration message from the SAS.

7.1.1.5.2 SASDeregistrationRequest Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns:common="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

10/21/16 CableLabs 41
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

7.1.1.5.2.1 SASDeregistrationRequest Example with no StatusCode

The following is an SASDeregistrationRequest with no StatusCode.
<common:SASDeregistrationRequest
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A"
acquisitionPointIdentity="AcquisitionPointFooBar">
</common:SASDeregistrationRequest>

7.1.1.5.2.2 SASDeregistrationRequest Example with StatusCode

The following is an SASDeregistrationRequest with StatusCode. The StatusCode provides
supplemental data associated with the deregistration request. The detailCode indicates the SAS is
shutting down. A detailCode of 6 could be passed indicating a restart.
<common:SASDeregistrationRequest
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A"
acquisitionPointIdentity="AcquisitionPointFooBar">
<common:StatusCode classCode="3" detailCode="5">
<core:Note>AcquisitionPointFooBar shutting down.</core:Note>
</common:StatusCode>
</common:SASDeregistrationRequest>

7.1.1.6 SASDeregistrationResponse
The SASDeregistrationResponse message is sent by the SPS in response to an
SASDeregistrationRequest.
If an sasToken attribute is present in the deregistration message, the SPS SHALL return the value
in the response.
The deregistration message SHALL be accepted and acknowledged as successful based on the
acquisitionPointIdentity. If the token passed in the deregistration message does not match the
token retained by the SPS, the deregistration SHALL still be accepted. The SPS MAY pass a
detailCode of 7 in the response to indicate the mismatch. See section 6.1.

42 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

The following XML payload is passed:

Figure 12 - SASDeregistrationResponse XML Schema

7.1.1.6.1 SASDeregistrationResponse Semantics

Table 13 - SASDeregistrationResponse Elements and Attributes

Name Required Description

acquisitionPointIdentity Y Identity of the SAS from the deregistration message
SHALL be supplied.
sasToken C If present in the SAS registration messages, it SHALL be
passed in the response message from the SAS.
StatusCode C StatusCode SHALL be populated if there is an error
while processing a registration request message.
StatusCode MAY be populated if the registration
message is successfully processed.
classCode C Set to 0 (zero) on success. Set to 1 (one) on error.
detailCode C Table 4.

10/21/16 CableLabs 43
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Name Required Description

Notes O Populate with additional details related to the
StatusCode.

7.1.1.6.2 SASDeregistrationResponse Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

7.1.1.6.2.1 SASDeregistrationResponse Example 1

Following indicates a successful SAS deregistration.
<common:SASDeregistrationResponse
acquisitionPointIdentity="AcquisitionPointFooBar"
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
<common:StatusCode classCode="0"/>
</common:SASDeregistrationResponse>

7.1.1.7 SPSDeregistrationRequest
The SPSDeregistrationRequest message used by the SPS to deregister from an SAS that was
previously registered with.

44 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

The following XML payload is passed:

Figure 13 - SPSDeregistrationRequest XML Schema

7.1.1.7.1 SPSDeregistrationRequest Semantics

Table 14 - SPSDeregistrationRequest Elements and Attributes

Name Required Description

signalProcessingIdentity Y The identification of the SPS deregistering SHALL be
specified.
sasToken C If present in the SAS registration messages, it SHALL
be passed in the deregistration message from the SAS.

10/21/16 CableLabs 45
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Name Required Description

spsToken C If present in the SPS registration messages, it SHALL
be passed in the deregistration message from the SPS.

7.1.1.7.2 SPSDeregistrationRequest Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

7.1.1.7.2.1 SPSDeregristrationRequest Example with no status code

Following is an SPSDeregistrationRequest with no StatusCode.
<common:SPSDeregistrationRequest
signalProcessingIdentity="SPSControlPoint"
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C"
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
</common:SPSDeregistrationRequest>

7.1.1.8 SPSDeregistrationResponse
The SPSDeregistrationResponse message is sent by the SAS in response to an
SPSDeregistrationRequest.
If an spsToken attribute is present in the deregistration message, the SAS SHALL return the
value in the response.
The deregistration message SHALL be accepted and acknowledged as successful based on the
signalProcessingIdentity. If the token passed in the deregistration message does not match the
token retained by the SAS, the deregistration SHALL still be accepted. The SAS MAY pass a
detailCode of 7 in the response to indicate the mismatch.

46 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

The following XML payload is passed:

Figure 14 - SPSDeregistrationResponse XML Schema

7.1.1.8.1 SPSDeregistrationResponse Semantics

Table 15 - SPSDeregistrationResponse Elements and Attributes

Name Required Description

signalProcessingIdentity Y The identification of the SPS deregistering SHALL be
specified.
spsToken C If present in the SPS registration messages, it SHALL
be passed in the deregistration response message from
the SAS.

10/21/16 CableLabs 47
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Name Required Description

sasToken C If present in the SAS registration messages, it SHALL
be passed in the response message from the SAS.
StatusCode C StatusCode SHALL be populated if there is an error
while processing a registration request message.
StatusCode MAY be populated if the registration
message is successfully processed.
classCode C Set to 0 (zero) on success. Set to 1 (one) on error.
detailCode C See Table 4.
Notes O Populate with additional details related to the
StatusCode.

7.1.1.8.2 SPSDeregistrationResponse Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

7.1.1.8.2.1 SPSDeregistrationResponse Example 1 – Success

The following shows a successful SPS deregistration response sent from an SAS.
<common:SPSDeregistrationResponse spsToken="8064CCC0-D36B-41F6-9D09-
9B6D6FB1729C" signalProcessingIdentity="SPSControlPoint"
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
<common:StatusCode classCode="0"/>
</common:SPSDeregistrationResponse>

7.1.1.8.2.2 SPSDeregistrationResponse Example 2 – Mismatched Token

The following shows an unsuccessful SPSDeregistrationResponse sent from an SAS. The detail
code indicates a mismatched token. The example shows how to communicate the token or tokens
that don’t match.
<common:SPSDeregistrationResponse signalProcessingIdentity="SPSControlPoint">
<common:StatusCode classCode="1" detailCode="7">
<core:Note>Token mis-match - expected SAS token of xxxx</core:Note>
<core:Note>Token mis-match - expected SPS token of xxx </core:Note>
</common:StatusCode>
</common:SPSDeregistrationResponse>

7.1.1.9 ServiceCheckRequest
The ServiceCheckRequest message is sent by the SAS to an SPS or an SPS to an SAS to verify
the status of the end point. A ServiceStatusNotification message SHALL be received as a
response. (See section 7.1.1.10)

48 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 15 - ServiceCheckRequest XML Schema

7.1.1.9.1 ServiceCheckRequest Semantics

Table 16 - ServiceCheckRequest Elements and Attributes

Name Required Description

identity Y SHALL contain the SPS identity if the SPS is sending the
message. SHALL contain the SAS identity if the SAS is
sending the message.
spsToken C If present in the SPS registration messages, it SHALL be
passed in the ServiceCheckRequest message sent by the SAS
or SPS.
sasToken C If present in the SAS registration messages, it SHALL be
passed in the ServiceCheckRequest message sent by the SAS
or SPS.

10/21/16 CableLabs 49
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

7.1.1.9.2 ServiceCheckRequest Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

7.1.1.9.2.1 ServiceCheckRequest Example 1

Following illustrates a service check request that uses tokens.
<common:ServiceCheckRequest identity="endPointId1" spsToken="8064CCC0-D36B-
41F6-9D09-9B6D6FB1729C"
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
</common:ServiceCheckRequest>

7.1.1.10 ServiceStatusNotification
A ServiceStatusNotification is sent in response to a ServiceCheckRequest message. See section
7.1.1.9.
A ServiceStatusNotification MAY be sent asynchronously from an SAS to an SPS or from an
SPS to an SAS to report a change in status.

50 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 16 - ServiceStatusNotification XML Schema

7.1.1.10.1 ServiceStatusNotification Semantics

Table 17 - ServiceStatusNotification Elements and Attributes

Name Required Description

identity Y SHALL contain the SPS identity if the SPS is sending the
message. SHALL contain the SAS identity if the SAS is
sending the message.
spsToken C If present in the SPS registration messages, it SHALL be
passed in the service status notification message.

10/21/16 CableLabs 51
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Name Required Description

sasToken C If present in the SAS registration messages, it SHALL be
passed in the service status notification message.
StatusCode O StatusCode SHALL be populated if there is status event to
report. StatusCode MAY be populated if the end point has no
status event to report.
classCode O Set to 0 (zero) on success. Set to 1 (one) on error.
detailCode O See Table 4
Notes O Populate with additional details related to the StatusCode.

7.1.1.10.2 ServiceStatusNotification Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

7.1.1.10.2.1 ServiceStatusNotification Example – Service Check Response

The following illustrates a positive response to a ServiceCheckRequest.
<common:ServiceStatusNotification identity="EndPointFoo" spsToken="8064CCC0-
D36B-41F6-9D09-9B6D6FB1729C"
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A" >
</common:ServiceStatusNotification>

7.1.1.10.2.2 ServiceStatusNotification Example – Error Condition or Status Change

The following illustrates a negative response to a ServiceCheckRequest. It also represents a
ServiceStatusNotification that is sent asynchronously to indicate a change in status. In this case
the StatusCode indicates that the end point is shutting down. Other error conditions or status can
also be communicated in this manner.
<common:ServiceStatusNotification identity="EndPointFoo" spsToken="8064CCC0-
D36B-41F6-9D09-9B6D6FB1729C"
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
<common:StatusCode classCode="3" detailCode="5">
<core:Note> xxx is shutting down.</core:Note>
</common:StatusCode>
</common:ServiceStatusNotification>

7.1.2 General Processing Messages

The messages in this are general purpose and can be used by an SAS end point performing
signal, manifest or other processing activities.
The following illustrates the message exchanges between the SAS (ex. Transcoder) and an SPS
(ex. POIS) to initiate (URIProcessingRequest) and monitor (process status messages) a batch
process.

52 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Signal Acquisition System Initiated Request

Operator Repository for Signal Processing System Signal Acquisition System

Content Provider Control System
Metadata and Content (ex. PO System/SCTE 130 POIS) (ex. Transcoder, clamper)

CableLabs Metadata 3.0

And Asset Delivered
CableLabs Metadata 3.0
PO/Signal Metadata Direct Signal Acquisition
System To Process Content
URI Processing Request
Build complete signal processing
notification based on the Cablelabs signal
Metadata

Signal Processing Notification

Access the content file

Generate the content file(s)

Process Status Notification

Process Status Acknowledgement Process Status Messages can be

used to obtain or report
(progress, normal/abnormal
Process Status Request completion, etc.) for entire batch
or a specific signal that is part of
a batch.
Process Status Response

Figure 17 - Mode 1 Message Exchange

The following illustrates the message exchanges between the an SPS (ex. POIS) and an SAS (ex.
Transcoder) to initiate (SignalProcessingNotification (see section 8.2.2)), and monitor (process
status messages) a batch process.
Signal Processing System Initiated Request

Operator Repository for Signal Processing System Signal Acquisition System

Content Provider Control System
Metadata and Content (ex. PO System/SCTE 130 POIS) (ex. Transcoder, clamper)

CableLabs Metadata 3.0

And Asset Delivered
CableLabs Metadata 3.0
PO/Signal Metadata
Direct Signal Processing
System To Process Content
Build complete signal processing
notification based on the Cablelabs signal
Metadata

Signal Processing Notification

Access the content file

Generate the content file(s)

Process Status Notification

Process Status Messages can be

Process Status Acknowledgement used to obtain or report
(progress, normal/abnormal
completion, etc.) for entire batch
Process Status Request or a specific signal that is part of
a batch.

Process Status Response

Figure 18 - Mode 2 Message Exchange

10/21/16 CableLabs 53
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

In both modes of operation, the ProcessStatusNotification/ProcessStatusAcknowledgement and

ProcessStatusRequest/ProcessStatusResponse messages are used to obtain or report on the status
of a batch request. For example, in both modes, an implementation MAY require a
ProcessStatusNotification be sent by the Signal Acquisition System or issue a
ProcessStatusRequest from the Signal Processing System as soon as the
SignalProcessingNotification message is sent to the Signal Acquisition System.

7.1.2.1 ProcessStatusNotification
The ProcessStatusNotification message is used to send status information about a process from
an SAS to an SPS. This includes a UriProcessingRequest identified by a batchId or processing
related to a signal, acquisitionSignalID or signalPointID.
If the Signal Processing System does not recognize or support the specified attribute/element or
its semantics, the Signal Processing System is to ignore the data.
The following XML payload is returned:

54 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 19 - ProcessStatusNotification XML Schema

10/21/16 CableLabs 55
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

7.1.2.1.1 ProcessStatusNotification Semantics

Table 18 - ProcessStatusNotification Elements and Attributes

Name Required Description

acquisitionPointIdentity Y The identification of the SAS reporting status
SHALL be specified.
acquisitionSignalID C An optional acquisitionSignalID MAY be specified.
Omit if reporting on multiple signals using multiple
signal notification elements.
signalPointID C An optional signal point identity MAY be specified.
This signal point identity SHOULD come from the
response signal passed in a signal processing
notification message. Omit if reporting on multiple
signals using multiple signal notification elements.
batchId C If reporting on a batch process, the batchId SHALL
be specified.
spsToken C Optional token that uniquely identifies the SPS. If
the spsToken was passed in the registration message,
the SPS SHALL pass the same token in this
message.
sasToken C Optional token that uniquely identifies the SAS
registration. If it was passed in the SAS registration
message it SHALL be passed in this message.
StatusCode O Omit if reporting on multiple signals using multiple
signal notification elements.
MultipleSignalNotification O If reporting on multiple signals, pass two or more
elements including the acquisition signal identity,
signal point identity and optional status code
element.

An acquisitionSignalID, signalPointID and/or batchId MAY be supplied depending on the use

case.
1. Only batchId is passed to report the status of a batch.
2. acquisitionSignalID and signalPointID AND/OR batchId are passed if reporting on the
processing of a specific acquisitionSignalID and signalPointID in a batch.
3. Only acquisitionSignalID and signalPointID is passed to report status on a specific
acquisitionSignalId during a non-batch process.
StatusCode information SHALL also be returned. See Section 6.1 for more information on
StatusCode. The classCode attribute SHALL be compliant with Table 3 in Section 6.1.1. The
values returned SHALL be compliant with the following:
• Return 0 (Success) upon successful completion of an operation.

56 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

• Return 1 (Error) upon unsuccessful complete of an operation. A detailCode value from

Table 4 in Section 6.1.1 SHOULD also be returned.
• Return 3 (Information) if the batch operation has not yet completed or if other details on
processing need to be returned.
One or more Note Elements SHOULD also be supplied to provide additional details.

7.1.2.1.2 ProcessStatusNotification Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:sig="urn:cablelabs:md:xsd:signaling:3.0"
xmlns:content="urn:cablelabs:md:xsd:content:3.0"
xmlns:scte35="http://www.scte.org/schemas/35/2016"
xmlns:common="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

7.1.2.1.2.1 Successful Process Status Notification Message

The SAS notifies the SPS that it has successfully completed a URI request.
<common:ProcessStatusNotification
acquisitionPointIdentity="Batch_Processing_Point_1"
batchId="27b777c1ee9941479677b56203953300"spsToken="8064CCC0-D36B-41F6-9D09-
9B6D6FB1729C"
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
<common:StatusCode classCode="0">
<core:Note>Processing completed</core:Note>
</common:StatusCode>
</common:ProcessStatusNotification>

7.1.2.1.2.2 Partially Complete Process Status Notification Message

The SAS notifies the SPS that it has completed 75% of a URI request.
<common:ProcessStatusNotification
acquisitionPointIdentity="Batch_Processing_Point_1"
batchId="27b777c1ee9941479677b56203953300" spsToken="8064CCC0-D36B-41F6-9D09-
9B6D6FB1729C"
sasToken="9A8E383B-2D1F-4A73-9888-8647411B926A">
<common:StatusCode classCode="3">
<core:Note>Processing 75% complete</core:Note>
</common:StatusCode>
</common:ProcessStatusNotification>

7.1.2.1.2.3 Failed Batch Status Notification Message

The transcoder notifies the POIS that it has failed to complete a URI request due to an unfound
resource.
<common:ProcessStatusNotification
acquisitionPointIdentity="Batch_Processing_Point_1"
batchId="27b777c1ee9941479677b56203953300"
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C" sasToken="9A8E383B-2D1F-
4A73-9888-8647411B926A">

10/21/16 CableLabs 57
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

<common:StatusCode classCode="1" detailCode="2">

<core:Note>Source not found.</core:Note>
</common:StatusCode>
</common:ProcessStatusNotification>

7.1.2.1.2.4 Redundant SPS Responses Example

In a redundant SPS configuration, the SAS notifies each SPS end point on the disposition of a
signal processing notification it received. This example assumes that while the SAS will send a
signal processing event to two SPS end points, it will only apply one of the two signal processing
notifications. This same use case is applicable to asynchronous signal processing notifications
sent by redundant SPS to a single SAS.
The following represents a signal processing notification message sent to an SAS from one of the
SPSs. Similar messages will be sent from other SPS that is called for redundancy. With the
exception of the signal processing identity, the signal point identities and SCTE 35 binary
elements, the signal processing notification will be identical. The SCTE 35 binary elements are
not involved in the signal processing notification message construction and processing. See
Section 8.2.2 for description of signal processing notification message.
<signal:SignalProcessingNotification
acquisitionPointIdentity="SignalAcquisitionSystem1"
signalProcessingIdentity="SignalProcessingSystem1" spsToken="spsToken1"
sasToken="sasToken1">
<!-- Advertising Out Point -->
<signal:ResponseSignal action="create"
acquisitionPointIdentity="SignalAcquisitionSystem1"
acquisitionSignalID="oZOhF8NVSwmwDF0XSv5bRg=="
signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz0">
<sig:UTCPoint utcPoint="2016-02-08T22:35:16Z"/>
<scte35:Binary signalType="SpliceInfoSection"

>/DBwAAAAAAAAAP/wBQb/AAAAAABaAlhDVUVJAAAAAn//AABSZcANRAoMFHeL5eP2AAAAAAAACgwU
d4vl4/YAAAAAAAAJJlNJR05BTDpMeTlFTUd4S1IwaEZaVXRwTUhkQ1VWWm5SVUZuWnowNgEB1Dao2
g==</scte35:Binary>
</signal:ResponseSignal>
<!-- Advertising In Point 1 - at 60 seconds -->
<signal:ResponseSignal action="create"
acquisitionPointIdentity="SignalAcquisitionSystem1"
acquisitionSignalID="3hH7oSJgRp2EkNv8SmyzTA=="
signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz1">
<sig:UTCPoint utcPoint="2016-02-08T22:36:16Z"/>
<scte35:Binary signalType="SpliceInfoSection"

>/DBrAAAAAAAAAP/wBQb/AAAAAABVAlNDVUVJAAAAAn+/DUQKDBR3i+Xj9gAAAAAAAAoMFHeL5eP2
AAAAAAAACSZTSUdOQUw6THk5RU1HeEtSMGhGWlV0cE1IZENVVlpuUlVGblp6MTcBA6QTOe8=</sct
e35:Binary>
</signal:ResponseSignal>
<!-- Advertising In Point 1 - at 90 seconds -->
<signal:ResponseSignal action="create"
acquisitionPointIdentity="SignalAcquisitionSystem1"
acquisitionSignalID="50KmsPriRDWT19pxV24ZLg=="
signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz2">
<sig:UTCPoint utcPoint="2016-02-08T22:36:46Z"/>
<scte35:Binary signalType="SpliceInfoSection"

58 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

>/DBrAAAAAAAAAP/wBQb/AAAAAABVAlNDVUVJAAAAAn+/DUQKDBR3i+Xj9gAAAAAAAAoMFHeL5eP2
AAAAAAAACSZTSUdOQUw6THk5RU1HeEtSMGhGWlV0cE1IZENVVlpuUlVGblp6MjcCA7aP1FI=</sct
e35:Binary>
</signal:ResponseSignal>
<!-- Advertising In Point 1 - at 120 seconds -->
<signal:ResponseSignal action="create"
acquisitionPointIdentity="SignalAcquisitionSystem1"
acquisitionSignalID="pZ2qXPBIRTapVdildVlD6A=="
signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz3">
<sig:UTCPoint utcPoint="2016-02-08T22:37:16Z"/>
<scte35:Binary signalType="SpliceInfoSection"

>/DBrAAAAAAAAAP/wBQb/AAAAAABVAlNDVUVJAAAAAn+/DUQKDBR3i+Xj9gAAAAAAAAoMFHeL5eP2
AAAAAAAACSZTSUdOQUw6THk5RU1HeEtSMGhGWlV0cE1IZENVVlpuUlVGblp6MzcDA7j7jzk=</sct
e35:Binary>
</signal:ResponseSignal>
<!-- Condition all content with 15 sec segments with 2 second fragments -
->
<signal:ConditioningInfo
acquisitionSignalIDRef="oZOhF8NVSwmwDF0XSv5bRg==">
<signal:Segment fragmentDuration="PT2S">PT15.0S</signal:Segment>
</signal:ConditioningInfo>
<signal:ConditioningInfo
acquisitionSignalIDRef="3hH7oSJgRp2EkNv8SmyzTA==">
<signal:Segment fragmentDuration="PT2S">PT15.0S</signal:Segment>
</signal:ConditioningInfo>
<signal:ConditioningInfo
acquisitionSignalIDRef="50KmsPriRDWT19pxV24ZLg==">
<signal:Segment fragmentDuration="PT2S">PT15.0S</signal:Segment>
</signal:ConditioningInfo>
<signal:ConditioningInfo
acquisitionSignalIDRef="pZ2qXPBIRTapVdildVlD6A==">
<signal:Segment fragmentDuration="PT2S">PT15.0S</signal:Segment>
</signal:ConditioningInfo>
</signal:SignalProcessingNotification>

In the following message, the SPS "SignalProcessingSystem1" is notified that all its signals were
applied.
<common:ProcessStatusNotification
acquisitionPointIdentity="SignalAcquisitionSystem1"
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C" sasToken="9A8E383B-2D1F-
4A73-9888-8647411B926A">
<!-- confirm out point -->
<common:MultiSignalNotification
acquisitionSignalID="oZOhF8NVSwmwDF0XSv5bRg=="
signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz0">
<common:StatusCode classCode="0"/>
</common:MultiSignalNotification>
<!-- confirm in point 1 -->
<common:MultiSignalNotification
acquisitionSignalID="3hH7oSJgRp2EkNv8SmyzTA=="
signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz1">
<common:StatusCode classCode="0"/>
</common:MultiSignalNotification>

10/21/16 CableLabs 59
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

<!-- confirm in point 2 -->

<common:MultiSignalNotification
acquisitionSignalID="50KmsPriRDWT19pxV24ZLg=="
signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz2">
<common:StatusCode classCode="0"/>
</common:MultiSignalNotification>
<!-- confirm in point 3 -->
<common:MultiSignalNotification
acquisitionSignalID="pZ2qXPBIRTapVdildVlD6A=="
signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz3">
<common:StatusCode classCode="0"/>
</common:MultiSignalNotification>
</common:ProcessStatusNotification>

In the following message, the SPS "SignalProcessingSystem2" is notified that none of its signals
were applied. The notification also provides the SPS identity and signal point identity that was
actually applied. The acquisition signal identity and signal point identifies passed in the
MultiSignalNotification elements are from SPS “SignalProcessingSystem2”. The signal point
identity and SPS identity passed in the Notes element are from the SPS data actually applied.
<common:ProcessStatusNotification
acquisitionPointIdentity="SignalAcquisitionSystem1"
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C" sasToken="9A8E383B-2D1F-
4A73-9888-8647411B926A">
<!-- out point indication -->
<common:MultiSignalNotification
acquisitionSignalID="LQx/snmJRDmjXqVOcWgVeA=="
signalPointID="nW6ZAN/JToa1EBo93EdnUg==">
<common:StatusCode classCode="0" detailCode="10">

<core:Note>applied:signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz0",signalProc
essingIdentity="SignalProcessingSystem1"</core:Note>
</common:StatusCode>
</common:MultiSignalNotification>
<!-- in point 1 indication -->
<common:MultiSignalNotification
acquisitionSignalID="TjfbeQ7XTtqbIgs/HS9EXA=="
signalPointID="mbs3BwEIRj+auhIpqIr/HQ==">
<common:StatusCode classCode="0" detailCode="10">

<core:Note>applied:signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz1",signalProc
essingIdentity="SignalProcessingSystem1"</core:Note>
</common:StatusCode>
</common:MultiSignalNotification>
<!-- in point 2 indication -->
<common:MultiSignalNotification
acquisitionSignalID="Qsk5Ki5HSDuZtNuUd431xg=="
signalPointID="2VL0dZ+0QIOdUej7WAEhYg==">
<common:StatusCode classCode="0" detailCode="10">

<core:Note>applied:signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz2",signalProc
essingIdentity="SignalProcessingSystem1"</core:Note>
</common:StatusCode>
</common:MultiSignalNotification>
<!-- in point 3 indication -->
<common:MultiSignalNotification
acquisitionSignalID="bwnnSzRvSciG7oBBZlDH3w=="

60 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

signalPointID="rahNYTfYTDiIAJWj4KiV+A==">
<common:StatusCode classCode="0" detailCode="10">

<core:Note>applied:signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz3",signalProc
essingIdentity="SignalProcessingSystem1"</core:Note>
</common:StatusCode>
</common:MultiSignalNotification>
</common:ProcessStatusNotification>

7.1.2.2 ProcessStatusAcknowledgement
The ProcessStatusAcknowledgement message sent from the SPS to the SAS is used to
acknowledge a ProcessStatusNotification (see Section 7.1.1.1) message.
If the signal processing system does not recognize or support the specified attribute/element or
its semantics, the signal processing system is to ignore the data.
The following XML payload is returned:

10/21/16 CableLabs 61
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 20 - ProcessStatusAcknowledgement XML Schema

7.1.2.2.1 ProcessStatusAcknowledgement Attributes

Table 19 - ProcessStatusAcknowledgement Attributes

Name Required Description

acquisitionPointIdentity O The identification of the processing point reporting status
MAY be specified.
acquisitionSignalID O An optional acquisitionSignalID MAY be specified.
batchId O An optional batchId attribute MAY be specified.

62 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Name Required Description

spsToken O Optional token that uniquely identifies the SPS. If the
spsToken was passed in the registration message, the SPS
SHALL pass the same token in this message.
sasToken O Optional token that uniquely identifies the SAS
registration. If it was passed in the SAS registration
message it SHALL be passed in this message.

The acquisitionSignalID and batchId values, if present, SHALL be returned as passed in the
ProcessStatusNotification message. StatusCode information MAY also be returned. See Section
6.1 for more information on StatusCode.

7.1.2.2.2 ProcessStatusAcknowledgement Example

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

7.1.2.2.2.1 ProcessStatusAcknowledgement Message

The SPS acknowledges the SAS process status notification message. The notes element MAY be
populated with data useful to operational or other applications.
<common:ProcessStatusAcknowledgement
acquisitionPointIdentity="Batch_Processing_Point_1"
batchId="27b777c1ee9941479677b56203953300"
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C" sasToken="9A8E383B-2D1F-
4A73-9888-8647411B926A">
<common:StatusCode classCode="0">
<core:Note>Acknowledge</core:Note>
</common:StatusCode>
</common:ProcessStatusAcknowledgement>

7.1.2.3 ProcessStatusRequest
The ProcessStatusRequest message is sent from an SPS to an SAS to obtain status on a process.
A ProcessStatusResponse (see Section7.1.2.4) SHALL be sent in response to a
ProcessStatusRequest message. This includes a UriProcessingRequest identified by a batchId or
processing related to an acquisitionSignalID.
If the signal acquisition system does not recognize or support the specified attribute/element or
its semantics, the signal acquisition system SHALL ignore the data.
The following XML payload is returned:

10/21/16 CableLabs 63
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 21 - ProcessStatusRequest XML Schema

7.1.2.3.1 ProcessStatusRequest Attributes

Table 20 - ProcessStatusRequest Attributes

Name Required Description

acquisitionPointIdentity Y The identification of the processing point reporting status
SHALL be specified.
acquisitionSignalID O An optional acquisitionSignalID MAY be specified.

64 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Name Required Description

batchId C If requesting status of a batch, the batchId SHALL be
specified.
spsToken C Optional token that uniquely identifies the SPS. If the
spsToken was passed in the SPS registration message, the
SAS token SHALL passed in this message.
sasToken C Optional token that uniquely identifies the SAS. If the
sasToken was passed in the SAS registration message, the
SAS token SHALL passed in this message.

An acquisitionSignalID and/or batchId MAY be supplied depending on the use case.

1. Only batchId is passed to request the status of a batch.
2. acquisitionSignalID and/or batchId are passed if requesting on the processing of a
specific acquisitionSignalID in a batch.
3. Only acquisitionSignalID is passed to request status on a specific acquisitionSignalId
during a non-batch process.

7.1.2.3.2 ProcessStatusRequest Example

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

7.1.2.3.2.1 Process Status Request Message

A batch processing control system acting as an SPS queries the SAS about processing of a
specific URI request.
<common:ProcessStatusRequest
acquisitionPointIdentity="Batch_Processing_Point_1"
batchId="27b777c1ee9941479677b56203953300"
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C" sasToken="9A8E383B-2D1F-
4A73-9888-8647411B926A"/>

7.1.2.4 ProcessStatusResponse
The ProcessStatusResponse message is sent from the SAS to the SPS in response to a
ProcessStatusRequest message (see Section 7.1.2.3). This includes an UriProcessingRequest
identified by a batchId or processing related to an acquisitionSignalID.
If the signal processing system does not recognize or support the specified attribute/element or
its semantics, the signal processing system is to ignore the data.
The following XML payload is returned:

10/21/16 CableLabs 65
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 22 - ProcessStatusResponse XML Schema

7.1.2.4.1 ProcessStatusResponse Attributes

Table 21 - ProcessStatusResponse Attribute

Name Required Description

acquisitionPointIdentity Y The identification of the processing point reporting status
SHALL be specified.

66 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Name Required Description

acquisitionSignalID C If reporting status of a specific signal, an
acquisitionSignalID SHALL be specified.
batchId C If reporting status of a batch (ex. URI processing
request), the batchId SHALL be specified.
spsToken C Optional token that uniquely identifies the SPS. If the
spsToken was passed in the SPS registration message, the
SAS token SHALL be passed in this message.
sasToken C Optional token that uniquely identifies the SAS. If the
sasToken was passed in the SAS registration message,
the SAS token SHALL be passed in this message.

The acquisitionSignalID and batchId values, if present, SHALL be returned as passed in the
ProcessStatusRequest message.
StatusCode information SHALL also be returned. See Section 6.1 for more information on
StatusCode. The classCode attribute SHALL be compliant with Table 3 in Section 6.1.1. The
values returned SHALL be compliant with the following:
• Return 0 (Success) upon successful completion of a batch operation.
• Return 1 (Error) upon unsuccessful complete of a batch operation. A detailCode value
from Table 4 in Section 6.1.1 SHOULD also be returned.
• Return 3 (Information) if the batch operation has not yet completed.
One or more Note Elements SHOULD also be supplied to provide additional details.

7.1.2.4.2 ProcessStatusResponse Example

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

See Section 7.1.2.2.2 for addition examples of the usage of the StatusCode Element.

7.1.2.4.2.1 Successful Process Status Response Message

The transcoder acting as an SPS responds to the POIS acting as an SAS that the batch is 75%
completed.
<common:ProcessStatusResponse
acquisitionPointIdentity="Batch_Processing_Point_1"
batchId="27b777c1ee9941479677b56203953300"
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C" sasToken="9A8E383B-2D1F-
4A73-9888-8647411B926A">
<common:StatusCode classCode="0">
<core:Note>In process – 75% complete</core:Note>
</common:StatusCode>

10/21/16 CableLabs 67
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

</common:ProcessStatusResponse>

7.1.2.5 SignalStateRequest
The SignalStateRequest message sent from an SAS to an SPS is used to obtain conditioning
information for an asset (ex. a Linear Stream). An applicable use case would be to handle
failover of an SAS (ex. transcoder processing a linear stream). When the new SAS comes on
line, it would reach out to the SPS to determine the state of processing (ex. Active signals in a
linear stream that indicate whether the stream is in a blackout or not). The SPS is expected to
send the appropriate notification message in response (Ex. a SignalProcessingNotification with
all known SCTE 35 segments and related information. See section 8.2.2 and the example in
section 8.2.2.2.8.).
The following XML payload is passed in the SignalStateRequest message:

68 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 23 - SignalStateRequest XML Schema

10/21/16 CableLabs 69
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

7.1.2.5.1 SignalStateRequest Attributes

Table 22 - SignalStateRequest Attributes

Name Required Description

acquisitionPointIdentity Y The acquisitionPointIdentity attribute SHALL be
specified. A unique identity of the acquisition point
identifying the signal acquisition system (ex. transcoder)
used to process the content available at the specified URI.
uriId O If present, SHALL be set to the identifier for asset to
return the status for.
startDateTime O If present, SHALL provide a filter to the Signal
Processing System to indicate the starting date/time for
the request. The Signal Processing System SHALL return
a SignalProcessingNotification containing all event
records received at the starting date/time and later for the
acquisition point identified in acquisitionPointIdentity
spsToken C Optional token that uniquely identifies the SPS. If the
spsToken was passed in the SPS registration message, the
SAS token SHALL be passed in this message.
sasToken C Optional token that uniquely identifies the SAS. If the
sasToken was passed in the SAS registration message, the
SAS token SHALL be passed in this message.

7.1.2.5.2 SignalStateRequest Example

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

7.1.2.5.2.1 SignalStateRequest Message for all active signals

Request all active signals for SAS acquisition point “mso.com/ProcessingPt”. See 8.2.2 for
associated SignalProcessingNotification message.
<common:SignalStateRequest
acquisitionPointIdentity="mso.com/ProcessingPt"
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C" sasToken="9A8E383B-2D1F-
4A73-9888-8647411B926A"/>

7.1.2.5.2.2 SignalStateRequest Message for signals with start time

Request all signals for SAS acquisition point “mso.com/ProcessingPt” starting at a specified
date/time. See 8.2.2.2.8 for associated SignalProcessingNotification message that uses this
message for SAS end point recovery.
<common:SignalStateRequest

70 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

acquisitionPointIdentity="mso.com/ProcessingPt"
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C" sasToken="9A8E383B-2D1F-
4A73-9888-8647411B926A"
startDateTime="2016-03-01T18:13:51.0"/>

7.1.2.6 UriProcessingRequest
The UriProcessingRequest message is used to obtain conditioning information for URI based
content. See Section 8.2.2 for a sample SignalProcessingNotification message returned in
response to a UriProcessingRequest.
If the Signal Processing System does not recognize or support the specified attribute/element or
its semantics, the Signal Processing System is to ignore the data.
The following XML payload is returned:

10/21/16 CableLabs 71
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 24 - UriProcessingRequest XML Schema

72 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

7.1.2.6.1 UriProcessingRequest Attributes

Table 23 - UriProcessingRequest Attributes

Name Required Description

acquisitionPointIdentity O The acquisitionPointIdentity attribute MAY be specified.
A unique identity of the acquisition point identifying the
signal acquisition system (ex. transcoder) used to process
the content available at the specified URI.
batchId Y The batchId attribute SHALL be specified. The batchId
uniquely identifies the request. This batchId is passed on
all subsequent ESAM messages specific to the batch.
uriId Y SHALL be set to the identifier for asset being processed.
spsToken C Optional token that uniquely identifies this response. If the
spsToken was passed in the registration message, the SPS
SHALL pass the same token in this request.
sasToken C Optional token that uniquely identifies the SAS
registration. If it was passed in the SAS registration
message it SHALL be passed in this message.

7.1.2.6.2 UriProcessingRequest Example

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

7.1.2.6.2.1 Batch Request Message

The file based processing system acting as an SAS notifies the POIS acting as an SPS that it is
about to process URI sourced content. See Section 8.2.2.2.6 for a sample response message.
<common:UriProcessingRequest
spsToken="8064CCC0-D36B-41F6-9D09-9B6D6FB1729C" sasToken="9A8E383B-2D1F-
4A73-9888-8647411B926A"
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
batchId="27b777c1ee9941479677b56203953300"
uriId="provider.com/Asset/UNVA2001081701004002"/>

7.2 Common API Types

7.2.1 Address
The Address element contains endpoint information. The XML value interpretation MAY be
specified using the optional @type attribute.

10/21/16 CableLabs 73
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Table 24 - Address

Name Required Description

type O An attribute uniquely identifying the interpretation of the
element’s value and the value SHALL NOT be empty.
(ex.HTTP, HTTPS)
<Value> Y Valid address (See section 7.2.1.1)

Figure 25 - Address Element XML Schema

7.2.1.1 Address Formats

ESAM uses common, well-defined address formats whenever possible. This section describe
these formats.
Table 25 - Address Formats

Format Description Example

IPv4 An Internet Protocol (IP) A basic IPv4 address.
version 4 address SHALL 171.70.222.82
conform to the format and An IPv4 address in a URL.
characteristics as defined by http://171.70.22.82
RFC 3986. See [RFC3986] for
additional details.
Typically, the address is
represented in dot decimal
notation (also known as
dotted quad notation, i.e.,
nnn.nnn.nnn.nnn).

74 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Format Description Example

IPv6 An Internet Protocol (IP) The following 6 addresses are all equivalent.
version 6 address SHALL 2001:0db8:0000:0000:0000:0000:1428:57ab
conform to the format and 2001:0db8:0000:0000:0000::1428:57ab
characteristics as defined by 2001:0db8:0:0:0:0:1428:57ab
RFC 3986. See [RFC3986] for 2001:0db8:0:0::1428:57ab
additional details.
2001:0db8::1428:57ab
Typically, the address is
written as eight groups of four 2001:db8::1428:57ab
hexadecimal digits An IPv6 address in a URL. (Note the required
having the form of brackets around the IPv6 address.)
xxxx:xxxx:xxxx:xxxx:xxxx:xx http://[2001:0db8:85a3:08d3:1319:8a2e:0370:73
xx:xxxx:xxxx, where each x 44]
represents a single hex
character of the 128-bit
address. Per RFC 3986, use of
the standard “::” MAY be used
to suppress repeating zeros.
HostName A host name to be resolved via
DNS.
Port An IPv4 or an IPv6 address An IPv4 address with a port identifier.
Identification MAY optionally include a port 171.70.222.82:8080
identifier as part of the An IPv4 address in a URL that includes a port
address. Port identification identifier.
SHALL conform to the format http://171.70.222.82:8080
and characteristics as An IPv4 address in a URL that includes a port
defined by RFC 3986. See identifier and an endpoint.
[RFC3986] for additional
http://64.13.147.67:8080/scte130/index.jsp
details. The individual
An IPv6 address with a port identifier.
specifications SHALL indicate
if a port value is optional or [2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:4
required as appropriate. 43
An IPv6 address included in a URL that
includes a port identifier.
https://[2001:0db8:85a3:08d3:1319:8a2e:0370:7
344]:443
An IPv6 address included in a URL that
includes a port identifier and an endpoint.
https://[2001:0db8:85a3:08d3:1319:8a2e:0370:7
344]:443/scte130/index.jsp

7.2.1.2 Address Element Examples

<Address type="HTTP">http://25.35.45.55:80/ESAM</Address>

10/21/16 CableLabs 75
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

<Address type="HTTPS">https://25.35.45.55:80/ESAM</Address>
<Address type="HTTPS">https:// [2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:443/ESAM</Address>

7.2.1.3 Address Status codes and notes

If a compatible address or type from the provided list is supported by an end point a class code of
0 (zero) SHALL be returned. A notes element SHALL NOT be included specifying the address
and type selected for each end point and API. For example, “end point name – API – address –
type”.
If no compatible address or type from the provided list is supported by an end point a class code
of 1 (one) and detail code of 8 SHALL be returned. A notes element SHALL NOT be included
describing the compatible addresses and types supported by the end point.

7.2.2 BatchInfo
For URI based processing, the BatchInfo element identifies the batch, and optionally identifies
the content source and one or more content destinations. The following table calls out specific
treatment of the attributes and elements that are part of the BatchInfo element.
The batchId attribute SHALL be specified. The batchId uniquely identifies the request and
SHALL be passed on all subsequent ESAM messages specific to the batch.
BatchInfo references the CableLabs Metadata 3.0 MovieType for the source and destination
elements (see [CONTENT 3.0]). The SourceURL SHALL be specified when using the
MovieType when specifying source or destination content.
Table 26 - BatchInfo

Name Required Description

batchId Y SHALL be set to a GUID. The batchId uniquely identifies the
request. This batchId is passed on all subsequent ESAM
messages specific to the batch.
Source O Optional element specifying the source of the content.
Destination O Optional element specifying the destination of the processed
content. One or more Destination elements MAY be
specified.

Table 27 provides usage detail of the CableLabs 3.0 content:MovieType element. In addition to
the attributes and elements listed in Table 27, an implementation MAY choose to use other
attributes and elements. Specific usage of those attributes and elements is out of scope of this
specification.
Table 27 - CableLabs content:MovieType Usage

Name Required Description

xsi:type Y SHALL be set to “content:MovieType”.
uriId Y SHALL be set to the identifier for asset referenced in
content:SourceUrl.

76 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Name Required Description

Content:SourceUrl Y SHALL be set to the URL to the content source to process or
destination to create.
Content:POGroupRef OMIT SHOULD NOT be present. If present, the value can be
ignored.
Content:SignalGroup OMIT SHOULD NOT be present. If present, the value can be
Ref ignored.

Figure 26 - BatchInfoType XML Schema

7.2.3 CallOut
The Callout element specifies a logical service’s message reception endpoints. The endpoints
MAY be specified as a single collective aggregation, on a per message type basis via the
@message attribute, or as a combination of the two techniques.
A single message exchange endpoint MAY be defined to handle all logical service messaging. If
a single endpoint is handling all messaging, there SHALL be only one Callout element present in
the defining specification announcement message and the Callout element’s @message attribute
SHALL NOT be used. The Callout element omitting the @message attribute is referred to as the
default endpoint.
If independent endpoints are desired, the Callout element’s @message attribute SHALL be used
and each Callout element SHALL contain a message name as specified by the defining logical
service.
If independent message exchange endpoints are desired for only a subset of endpoints, the
default endpoint MAY be used in conjunction with one or more additional Callout elements. All
message endpoints not specifically referenced by a @message attribute SHALL be available
through the default endpoint. This behavior allows a logical service to provide specific, message

10/21/16 CableLabs 77
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

exchange endpoints for one or more Callout endpoints while utilizing a single, general purpose
endpoint for all other messaging. If this description technique is used, there SHALL only be a
single Callout element omitting the @message attribute for the callout sequence as detailed by
the individual specifications (i.e., there SHALL be a maximum of one default endpoint for the
applicable callout sequence).
If no default endpoint is supplied and only a subset of the endpoints are provided in the message,
the unlisted endpoints SHALL be discovered by a different, unspecified mechanism which is
outside the scope of this specification.
Within the Callout element, the logical service MAY provide one or more Address elements. The
Address element describes a specific endpoint. If multiple Address elements are specified, the
Address elements SHALL be listed in preferred order of usage. The peer shall reject the Callout
element if no Address elements match the end points capability.
Table 28 - CallOut

Name Required Description

message O Specific message to be delivered via the supplied destination.
Omit if all messages are to be delivered to the specified
destination. Only one CallOut can omit the @message
attribute. See sections 7.1.1.1 for SAS and 7.2.4 for SPS
specific message values supported.
Address Y End point information. See section 7.2.1

78 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 27 - CallOutType XML Schema

7.2.4 SPSCallOuts
The SPSCallOuts element defines an SPS end point. The element includes a name for the end
point, the callouts for that end point (see 7.2.3) and attributes about the end point.
Table 29 - SPSCallOuts

Name Required Description

spsEndPointName Y A unique identity for signal processing end point.
SPSCallout Y One or more CallOuts associated with the SAS registering.
The message types supported are listed in Table 30.
Addresses specified in the CallOuts element SHOULD be
listed in preference order.
SPSAttribute O Optional list of attributes associated with the SPS end point.
See Table 31 for the list of Attribute values defined by this
specification.

10/21/16 CableLabs 79
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Table 30 - Message Values

Schema Message Reference

Common ProcessStatusNotification See section 7.1.2
Common SASDeregistrationRequest See section 7.1.1.5
Common ServiceCheckRequest See section 7.1.1.9
Common ServiceStatusNotification See section 7.1.1.10
Common SignalStateRequest See section 7.1.2.5
Manifest ManifestConfirmConditionEvent See section 9.2.1
Signal SignalProcessingEvent See section 8.2.1
Signal SignalProcessingNotification See section 8.2.2. Mainly for feedback to a
batch process.

Table 31 - AttributeName Values

attributeName Type Description

ServiceCheckInterval Duration If ServiceCheckRequest is specified, the time interval
between service checks. (ex. PT0.500S)
PRIVATE:.. Various Additional private AttributeName values MAY be
defined for a specific implementation. Such private
values SHALL be prefaced with “PRIVATE:”

80 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 28 - SPSCallOutsType XML Schema

10/21/16 CableLabs 81
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

8 SIGNAL CONFIRMATION AND CONDITIONING API

The Signal Confirmation and Conditioning API is used between a SAS (e.g., transcoder,
fragmenter, etc.), and a SPS (e.g., POIS). The originating system generates a signal event and
submits it using the defined JSON or XML payload to the processing system. The event
parameters provide as much information as possible about the end point and signal point.
Example signal points are a splice out/exit point indicated by an SCTE 35
splice_info_section()/splice_insert() command or an SCTE 35 segmentation_descriptor
associated with an SCTE 35 time_signal() command.
Using the provided information, the processing system confirms the validity of the signal and
finds the appropriate metadata (ex. Placement opportunity, SCTE 224 ESNI, etc.). Then, the
system derives information about the Signal Region start point and end point(s) with the
corrected UTC, NPT, and/or SCTE 35 point data. Specific identifiers (e.g., CableLabs 3.0 Signal
IDs) MAY also be obtained. Finally, the signal processing system generates a response
notification detailing how the acquisition system might condition the video content and provide
auxiliary data to be inserted for downstream usage. Additional information describing how
video content MAY be conditioned can be found in the CableLabs Content Encoding Profiles 3.0
Specification ([CEP 3.0]) and SCTE 172 ([SCTE 172]).

8.1 Signal Confirmation Use Cases

The following use cases are meant as a guideline for defining the schemas for the event and
notification elements and are not intended to be an exhaustive representation of the system
usage. The schemas are designed with extensibility features that are intended to support yet-to-
be-defined signaling models and formats.

8.1.1 SpliceInsert to Signal Ads

The content provider inserts an SCTE 35 splice insert marker into the stream to signal a
placement opportunity for a distributor to replace a national ad with a local ad. The transcoder
generates a SignalProcessingEvent element and sends it to the POIS endpoint. The POIS
confirms whether or not the signal is valid and notifies the transcoder of the condition points
within the stream with a SignalProcessingNotification message.

8.1.2 TimeSignal with SegmentationDescriptor to Signal an Ad

The content provider inserts an SCTE 35 time signal with segmentation descriptor into the
stream to signal a placement opportunity for a distributor to replace a national ad with a local ad.
The transcoder generates a SignalProcessingEvent element and sends it to the SPS endpoint. The
SPS confirms whether or not the signal is valid and notifies the transcoder of the condition points
within the stream with a SignalProcessingNotification message.

8.1.3 TimeSignal with SegmentationDescriptor to signal a Blackout

The content provider inserts an SCTE 35 time signal with segmentation descriptor into the
stream to signal the beginning of a region that may be subject to content restrictions (i.e.,
blackouts). The SAS generates a SignalProcessingEvent element and sends it to the SPS
endpoint. The SPS confirms whether or not the signal is a valid blackout and notifies the

82 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

transcoder of the condition points within the stream and includes a directive to repeat the signal
for a set amount of time using the SignalProcessingNotification message.

8.1.4 Normalize Signal Format

In order to provide a uniform signal to the downstream application, the SPS may be used to
replace (or modify elements of) the existing signal sent in the request event.

8.1.5 Out-of-Band Notification of Blackout

The content provider notifies the distributor of a blackout region in a way other than an SCTE 35
in-band signal as intended with this specification (ex. [SCTE 224]). The SPS is instructed to send
an out-of-band SignalProcessingNotification message to the transcoder detailing the insertion of
an in-band signal to be processed by downstream systems.

8.1.6 Regions Defined Using Signal Metadata

The content provider notifies the distributor of regions of interest in a URI referenced content
asset. The SPS (ex. POIS) will send SignalProcessingNotification messages in a synchronous or
asynchronous model to the transcoder detailing the insertion of in-band signaling, with unique
identifiers for the start and end of each region of interest, to be processed by downstream
systems. Regions of interest may be empty; that is, the start and end point of a region of interest
may point to the same position in an asset. A URI referenced content asset may not have any
regions of interest. In addition to NPT’s compliant with [CEP 3.0], BOS for start of stream and
EOS for end of stream SHALL be supported by an SAS supporting URI processing. BOS
designates a position prior to the first I/IDR frame. EOS designates a position following the last
frame in the file. For example, there may be no advertising in an asset received by a distributor.

8.2 Signal Confirmation and Conditioning API Messages

8.2.1 SignalProcessingEvent
This element is a wrapper for the AcquiredSignal element described below in the following
sections. The wrapper is used to contain multiple signals within one event message.
The content of AcquiredSignal, generally an SCTE 35 descriptor, can be either fully parsed or
sent as binary payload. This is expressed as a choice in the AcquiredSignal element so that
intermediary systems that are not interested in the content of the event can forward it as a pass-
through element using the Binary data type.
The following XML payload is submitted to the endpoint URI:

10/21/16 CableLabs 83
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 29 - SignalProcessingEvent XML Schema

84 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 30 - AcquiredSignal XML Schema

10/21/16 CableLabs 85
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

8.2.1.1 SignalProcessingEvent Semantics

8.2.1.1.1 AcquiredSignal Attributes and Elements

Table 32 - AcquiredSignal Attributes

Name Required Description

acquisitionPointIdentity Y A required string, typically a system-wide unique string,
identifying the transcoder at a specific site on a specific
channel/network feed. 

acquisitionSignalID Y A required string, typically a GUID, generated by the
transcoder identifying the signal point being confirmed.
signalPointID O Optional string passed by the signal acquisition system
identifying the signal.
acquisitionTime O Optional UTC Zulu combined date and time encoding of
the wall clock when the signal was captured (e.g., the
SCTE 35 splice_info_section() acquisition time). For
SCTE 35, this time value is not the splice time as
referenced by a cue time or time_signal(), but rather the
date and time of when the signal was received/encountered
by the acquisition transcoder. See Section 6.2 for additional
format information.
spsToken C Optional token that uniquely identifies the SPS registration.
If the spsToken was passed in the registration message, the
SAS SHALL pass the same token in this message.
sasToken C Optional token that uniquely identifies the SAS
registration. If it was passed in the SAS registration
message it SHALL be passed in this message.

Table 33 - AcquiredSignal Elements

Name Required Description

UTCPoint Y Required UTC Zulu combined date and time
encoding for the signal point. This UTC time
value typically SHOULD NOT match the
acquisitionTime value. The UTC time SHOULD
be sourced from an SCTE 35 time_descriptor
Choice ([SCTE 35]) if present in the source stream. If no
SCTE 35 time_descriptor is present in the source
stream, the SAS SHOULD set its own clock. See
Section 6.2 for additional format information.
NPTPoint Omit NPTPoint is not used with SignalProcessingEvent
messages.

86 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Name Required Description

StreamTimes O StreamTimes contains one or more time values
that are generated and interpreted by the
underlying subsystem. While implementation-
specific, this data is intended to be passed as is
through intervening systems unaltered.
SpliceInfoSection O Optional data from an SCTE 35 marker.
See[SCTE 35].
Choice Binary O Optional data from the SCTE 35 cue message (or
other signal) in Base64 encoded format. See
[SCTE 35]

8.2.1.2 SignalProcessingEvent Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:sig="urn:cablelabs:md:xsd:signaling:3.0"
xmlns:content="urn:cablelabs:md:xsd:content:3.0"
xmlns:common="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:scte35="http://www.scte.org/schemas/35/2016"
xmlns:signal="urn:cablelabs:iptvservices:esam:xsd:signal:1"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

SCTE 35 SpliceInsert (parsed)

The transcoder forwards a parsed SCTE 35 splice insert marker to the SPS using the following
syntax.
<signal:SignalProcessingEvent
<!-- acquisitionSignalID -->
<!-- GUID: 4A6A94EE-62FA-11E1-B1CA-882F4824019B -->
<signal:AcquiredSignal spsToken="spsToken1" sasToken="sasToken1"
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="4A6A94EE-62FA11E1B1CA882F4824019B"
acquisitionTime="2012-09-18T10:14:26Z">
<sig:UTCPoint utcPoint="2012-09-18T10:14:34Z"/>
<scte35:SpliceInfoSection>
<scte35:SpliceInsert spliceEventId="344568691"
outOfNetworkIndicator="true"
uniqueProgramId="55355">
<scte35:Program>
<scte35:SpliceTime ptsTime="4452723280"/>
</scte35:Program>
<scte35:BreakDuration autoReturn="false" duration="60"/>
</scte35:SpliceInsert>
</scte35:SpliceInfoSection>
</signal:AcquiredSignal>
</signal:SignalProcessingEvent>

10/21/16 CableLabs 87
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

8.2.1.2.1 SCTE 35 TimeSignal for a PlacementOpportunity

The SAS forwards a parsed event for a placement opportunity defined with SCTE 35 TimeSignal
command with a segmentation descriptor using the following syntax:
<signal:SignalProcessingEvent
<!-- acquisitionSignalID -->
<!-- GUID: 4A6A94EE-62FA-11E1-B1CA-882F4824019B -->
<signal:AcquiredSignal spsToken="spsToken1" sasToken="sasToken1"
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="4A6A94EE-62FA11E1B1CA882F4824019B"
acquisitionTime="2012-09-18T10:14:26Z">
<sig:UTCPoint utcPoint="2012-09-18T10:14:34Z"/>
<scte35:SpliceInfoSection>
<scte35:TimeSignal>
<scte35:SpliceTime ptsTime="4452723280"/>
</scte35:TimeSignal>
<!-- Segmentation descriptor -->
<!-- segmentTypeID of 50 is PlacementOpportunity Start -->
<scte35:SegmentationDescriptor segmentationEventId="99790150"
segmentationDuration="60"
segmentationTypeId="50" segmentNum="0" segmentsExpected="0"
>
<!-- upidType of 9 is an ADI identifier -->
<!-- UPID is hex encoding of SIGNAL:gFkRZZobSm+Nd7f5ccW1lA==
-->
<scte35:SegmentationUpid segmentationUpidType="9"
segmentationUpidFormat="hexbinary">5349474e414c3a67466b525a5a6f62536d2b4e6437
6635636357316c413d3d</scte35:SegmentationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
</signal:AcquiredSignal>
</signal:SignalProcessingEvent>

8.2.1.2.2 SCTE 35 TimeSignal for a Blackout

The SAS forwards an event for a program start boundary defined with a parsed SCTE 35
TimeSignal with a segmentation descriptor identifying the program using the following syntax:
<signal:SignalProcessingEvent
<!-- acquisitionSignalID -->
<!-- GUID: 4A6A94EE-62FA-11E1-B1CA-882F4824019B -->
<signal:AcquiredSignal spsToken="spsToken1" sasToken="sasToken1"
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="4A6A94EE62FA11E1B1CA882F4824019B"
acquisitionTime="2012-09-18T10:14:26Z">
<sig:UTCPoint utcPoint="2012-09-18T10:14:34Z"/>
<scte35:SpliceInfoSection>
<scte35:TimeSignal>
<scte35:SpliceTime ptsTime="4452723280"/>
</scte35:TimeSignal>
<!-- Segmentation descriptor -->
<!-- segmentationTypeId of 16 is Program Start -->
<scte35:SegmentationDescriptor segmentationEventId="99790150"
segmentationDuration="60"
segmentationTypeId="16" segmentNum="0" segmentsExpected="0">
<!-- upidType of 10 is an EIDR -->

88 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

<!-- UPID is hex encoding of 10.5240/DA73-37DD-11E7-9394-

DE6D-U -->
<scte35:SegmentationUpid segmentationUpidType="16"
segmentationUpidFormat="hexbinary"

>31302e353234302f444137332d333744442d313145372d393339342d444536442d55</scte35
:SegmentationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
</signal:AcquiredSignal>
</signal:SignalProcessingEvent>

8.2.1.2.3 SCTE 35 Binary

The transcoder forwards an unparsed SCTE 35 event in binary format to the POIS:
<signal:SignalProcessingEvent>
<!-- acquisitionSignalID -->
<!-- GUID: 4A6A94EE-62FA-11E1-B1CA-882F4824019B -->
<signal:AcquiredSignal spsToken="spsToken1" sasToken="sasToken1"
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="4A6A94EE62FA11E1B1CA882F4824019B"
acquisitionTime="2012-09-18T10:14:26Z">
<!-- Time derived by splice_time in splice_insert with pts_adjustment
from splice_info_section applied -->
<sig:UTCPoint utcPoint="2011-04-22T16:16:42.123Z"/>
<scte35:Binary
signalType="SpliceInfoSection">/D//AH/////////wDwUAAozof8/+1Ykjv1VmAAAAAP////
//////</scte35:Binary>
<!-- Stream times derived by the SPE -->
<sig:StreamTimes>
<sig:StreamTime TimeType="PTS" TimeValue="5022471834"/>
</sig:StreamTimes>
</signal:AcquiredSignal>
</signal:SignalProcessingEvent>

8.2.2 SignalProcessingNotification
Similar to the event message structure, the notification message is also a wrapper for the SCTE
35 AcquiredSignal type. The notification message contains multiple acquired signals and
condition points.
The SignalProcessingNotification element is used for both synchronous and asynchronous
processing. For synchronous processing, the SignalProcessingNotification is sent in response to
a SignalProcessingEvent. For asynchronous processing, the SignalProcessingNotification is sent
in response to a UriProcessingRequest for specific content (see Section 7.1.2.6) or as a request to
a processing element to initiate processing of specified content.
The notification message must explicitly define any updates to signals using the ResponseSignal
element with the associated action element. The SAS SHALL NOT be required to compose or
infer a new or modified signal based on any other information (e.g., SignalPointID). Therefore,
the SignalPointID must be explicitly provided as part of a new or updated signal in the
notification message if it is expected to be retrieved downstream by another device. Proprietary
means SHALL NOT be devised to circumvent this requirement.

10/21/16 CableLabs 89
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

If the SAS does not recognize or support the returned attribute/element or its semantics, the SAS
shall ignore the data.
ProcessStatusNotification messages SHOULD be sent by an SAS in response to all actions
defined in the SignalProcessingNotification message whether sent synchronously or
asynchronously. See section 7.1.2.1.
The following XML payload is returned:

90 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 31 - SignalProcessingNotification XML Schema

10/21/16 CableLabs 91
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 32 - ConditioningInfo XML Schema

92 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 33 - ResponseSignal XML Schema

10/21/16 CableLabs 93
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 34 - AlternateContent XML Schema

Figure 35 - EventSchedule XML Schema

94 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 36 - ThirdPartTag XML Schema

8.2.2.1 SignalProcessingNotification Semantics

Table 34 - SignalProcessingNotification Attributes and Elements

Name Required Description

signalProcessingIdentity Y Signal processing identity SHALL be specified on
asynchronous messages. Signal processing identity
SHOULD be specified when responding to a signal
processing event.
acquisitionPointIdentity O A unique identity of the acquisition point identifying the
signal acquisition system (ex. transcoder) at a specific
site on a specific channel/network feed for all of the
contained ResponseSignal or AlternateContentEvent
elements.
spsToken C Optional token that uniquely identifies this response. If
the spsToken was passed in the registration message, the
SPS SHALL pass the same token in this message.
sasToken C Optional token that uniquely identifies the SAS
registration. If it was passed in the SAS registration
message it SHALL be passed in this message.
ResponseSignal O Zero or more ResponseSignal elements SHALL be
passed describing signals and related actions.
ResponseSignal elements MAY tie to signals received in
a signal processing event or MAY create new signals.
See section 8.2.2.1.1.

10/21/16 CableLabs 95
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Name Required Description

ConditioningInfo O Zero or more ConditioningInfo elements SHALL be
passed providing conditioning constraints to be applied
starting at a specific signal or temporal position in a
stream. If ConditioningInfo is not present for a given
signal or temporal positon, while the action related to a
ResponseSignal is taken, no conditioning MAY be done.
See section 8.2.2.1.2.

8.2.2.1.1 ResponseSignal Semantics

This element extends the AcquisitionPointInfoType (see [CONTENT 3.0]),
Table 35 - ResponseSignal Attributes

Name Required Description

acquisitionPointIdentity Y A unique identity of the acquisition point identifying the
signal acquisition system (ex. transcoder) at a specific site
on a specific channel/network feed. The value of this
attribute SHALL take precedence over the acquisition
point identity attribute in the signal processing notification
element.
acquisitionSignalID Y Acquisition signal identity SHALL be supplied. If taking
an action on a signal passed in a signal processing event.
(See 8.2.1) the acquisition signal identity SHALL be from
the signal processing event. Acquisition signal identity
SHALL be generated by the SPS if creating a signal point
using the signal processing notification message either in
response to a signal processing event or asynchronously
using the signal processing notification message.
acquisitionTime O The acquisition time, if present in the signal processing
event message, MAY be returned in the signal processing
notification message.
signalPointID Y Signal point identity provides a unique identity for the
signal point action as part of a signal processing
notification message. The signal point identity SHALL be
generated by the SPS. Signal point identity SHOULD be
passed for all response signals.
spsToken C Optional token that uniquely identifies this response. If the
spsToken was passed in the registration message, the SPS
SHALL pass the same token in this message.
sasToken C Optional token that uniquely identifies the SAS
registration. If it was passed in the SAS registration
message it SHALL be passed in this message.

96 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Name Required Description

action Y Specifies the action to be taken:
create - add a signal
replace - replace the existing signal
delete - delete the signal
noop - do nothing, pass through
private:* - support private actions
A create action for an existing signal SHALL cause the
creation of an additional signal. Receipt of delete or
noop actions for an unknown signal is invalid and MAY
be ignored. Receipt of a replace action for an unknown
signal SHOULD be interpreted as create.

Table 36 - ResponseSignal Elements

Name Required Description

EventSchedule O Optional element to support repetition of a signal.
AlternateContent O Optional insertion schedule to support delayed insertion and
repetition.
ThirdPartyTag O Optional element to define an third party tag.

For synchronous processing, the UTCPoint Element SHALL be present and specify the UTC
position for the signal to create. For asynchronous processing, the NPTPoint Element SHALL be
present and specify the NPT offset per [CEP 3.0] for the signal position.
If the action is create and the ResponseSignal contains an SCTE 35, the Signal Acquisition
System SHOULD insert the new SCTE 35 no less than four (4) seconds prior to the indicated
UTCPoint splice time per SCTE 35 practice.

8.2.2.1.1.1 Alternate Content Semantics

Table 37 - AlternateContent Attributes

Name Required Description

altContentIdentity O A string representing the alternate stream to which the signal
processing needs to switch. If altContentIdentity is an empty
string or the altContentIdentity attribute is not present, the
signal processing needs to switch to the default stream.
zoneIdentity O A string that represents the location of this stream. Examples
MAY include: Ad Zone or VIRD.

10/21/16 CableLabs 97
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

8.2.2.1.2 ConditioningInfo Semantics

Table 38 - ConditioningInfo Attributes

Name Required Description

duration O An ISO Duration encoded total signal region duration,
typically a break/pod/avail duration, suggesting where
the transcoder SHOULD create an I/IDR frame for a
seamless splice return. For example, a one-minute avail
is encoded as "PT1M", a 30 second break is encoded as
"PT30S", and a 30500 millisecond break would be
coded as "PT30.5S". See Section 6.3 for additional
format information.
acquisitionSignalIDRef O Optional reference to an acquisitionSignalID
identifying the starting point for the conditioning info.
The acquisitionSignalID referenced MAY be passed in
the response signal or be a reference to the
acquisitionSignalID from the signal processing event
message. If this value is omitted, the conditioning
reference point SHALL be the first signal, if present in
the notification, or the current position (ex. NPT 0 for a
URI request).
startOffset O An ISO Duration indicating the relative position from a
signal.
• If @acquisitionSignalIDRef is omitted, the
first signal or current position SHALL be the
starting position.
• If @acquisitionSignalIDRef is present this
SHALL be the offset from the signal position

Table 39 - ConditioningInfo Elements

Name Required Description

Segment O Condition points for subdividing the break into smaller
units, not to be confused with HLS segments. Segments
are used to condition the video at the duration point per
CEP (See [CEP 3.0]) or SCTE 172 ([SCTE
172]). Content SHALL be subdivided into one or more
Segments of Segment length. The last Segment MAY
be less than Segment Length.

98 CableLabs 10/21/16
Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Table 40 - Segment Attribute

Name Required Description

fragmentDuration O If present, each Segment SHALL be further divided
into fragments as specific in fragmentDuration. If no
fragmentDuration is provided then the fragment size as
configured on the Signal Acquisition System SHALL
be used.

8.2.2.1.3 EventSchedule Semantics

Table 41 - EventScheduleType Attributes

Name Required Description

Interval O Optional repetition interval for a signal.

EventSchedule supports a choice of two scheduling models:

• Absolute start and end UTC times
• Relative (to signal time) start and end offsets
Table 42 - EventScheduleType Elements

Name Required Description

StartUTC Y SHALL be specified if using absolute timing.
EndUTC O Optional end time if StartUTC is specified.
StartOffset Y SHALL be specified if using relative timing.
EndOffset O Optional end offset if StartOffset is specified.

8.2.2.1.4 ThirdPartyTag Semantics

Table 43 - ThirdPartyTag Attributes

Name Required Description

owner Y URI of the tag owner
value C SHALL be specified if creating or replacing a tag.
The interpretation of the tag is specific to the owner
and is out of scope of this specification.

8.2.2.2 SignalProcessingNotification Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:sig="urn:cablelabs:md:xsd:signaling:3.0"
xmlns:content="urn:cablelabs:md:xsd:content:3.0"

10/21/16 CableLabs 99
OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

xmlns:scte35="http://www.scte.org/schemas/35/2016"
xmlns:common="urn:cablelabs:iptvservices:esam:xsd:common:1"
xmlns:signal="urn:cablelabs:iptvservices:esam:xsd:signal:1"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

8.2.2.2.1 Out-of-Band Notification

The SPS (ex. POIS) notifies the SAS (ex. Transcoder) to insert a signal indicating a program
start with the additional instructions to repeat every 5 seconds for the next two hours. This
notification message is not generated as a response to a signal processing event message sent by
the SAS.
<signal:SignalProcessingNotification
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
signalProcessingIdentity="SignalProcessingSystem1" spsToken="spsToken1"
sasToken="sasToken1">
<!-- Insert a program start boundary -->
<!-- GUID: 4A6A94EE-62FA-11E1-B1CA-882F4824019B -->
<signal:ResponseSignal
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1" action="create"
acquisitionSignalID="4A6A94EE62FA11E1B1CA882F4824019B"
signalPointID="4A6A94EE-62FA-11E1-B1CA-882F4824019B">
<sig:UTCPoint utcPoint="2012-09-18T10:00:00Z"/>
<scte35:SpliceInfoSection>
<!-- Time Signal Command -->
<scte35:TimeSignal>
<scte35:SpliceTime/>
</scte35:TimeSignal>
<!-- Segmentation descriptor -->
<!-- segmentTypeID of 16 is Program Start -->
<scte35:SegmentationDescriptor segmentationTypeId="16"
segmentationEventId="99790150"
segmentNum="1" segmentsExpected="1">
<!-- upidType of 10 is an EIDR -->
<!-- UPID is hex encoding of 10.5240/DA73-37DD-11E7-9394-
DE6D-U -->
<scte35:SegmentationUpid segmentationUpidType="10"
segmentationUpidFormat="hexbinary"

>31302e353234302f444137332d333744442d313145372d393339342d444536442d55</scte35
:SegmentationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
</signal:ResponseSignal>
<!-- Insert repeating program identification signals -->
<!-- GUID: 11b98ada-7cc0-4152-bc5c-1d2ab2909210 -->
<signal:ResponseSignal
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1" action="create"
acquisitionSignalID="11b98ada7cc04152bc5c1d2ab2909210"
signalPointID="11b98ada-7cc0-4152-bc5c-1d2ab2909210">
<sig:UTCPoint utcPoint="2012-09-18T10:00:05Z"/>
<scte35:SpliceInfoSection>
<!-- Time Signal Command -->
<scte35:TimeSignal>
<scte35:SpliceTime/>
</scte35:TimeSignal>

100 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

<!-- Segmentation descriptor -->

<!-- segmentTypeID of 1 is Content Identification -->
<scte35:SegmentationDescriptor segmentationTypeId="1"
segmentationEventId="99790150"
segmentNum="0" segmentsExpected="0">
<!-- upidType of 10 is an EIDR -->
<!-- UPID is hex encoding of 10.5240/DA73-37DD-11E7-9394-
DE6D-U -->
<scte35:SegmentationUpid segmentationUpidType="10"
segmentationUpidFormat="hexbinary"

>31302e353234302f444137332d333744442d313145372d393339342d444536442d55</scte35
:SegmentationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
<!-- Insert the signal every 5 seconds for the scheduled 2 hour
duration of the program -->
<signal:EventSchedule interval="PT5S">
<signal:StartUTC utcPoint="2012-09-18T10:00:05Z"/>
<signal:StopUTC utcPoint="2012-09-18T12:00:00Z"/>
</signal:EventSchedule>
</signal:ResponseSignal>
</signal:SignalProcessingNotification>

8.2.2.2.2 Replace existing signal

The SPS notifies the SAS that the signal identified by the acquisitionSignalID has to be replaced
with the one included in the notification payload. The StatusCode optional element MAY include
additional information about the directive.
<signal:SignalProcessingNotification >
<!-- acquisitionSignalID - replace the splice insert message-->
<!-- GUID: 4A6A94EE-62FA-11E1-B1CA-882F4824019B -->
<!-- provide the signal point ID -->
<!-- GUID: 805911659a1b4a6f8d77b7f971c5b594== -->
<!-- Base64 representation: gFkRZZobSm+Nd7f5ccW1lA -->
<common:StatusCode classCode="0">
<core:Note>insert normalized signal</core:Note>
</common:StatusCode>
<signal:ResponseSignal action="replace"
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
spsToken="spsToken1" sasToken="sasToken1"
acquisitionSignalID="4A6A94EE62FA11E1B1CA882F4824019B"
acquisitionTime="2006-05-04T18:13:51.0Z"
signalPointID="gFkRZZobSm+Nd7f5ccW1lA==">
<sig:UTCPoint utcPoint="2006-05-04T18:13:51.0Z"/>
<scte35:SpliceInfoSection>
<!-- Time Signal Command -->
<scte35:TimeSignal>
<scte35:SpliceTime/>
</scte35:TimeSignal>
<!-- Segmentation descriptor -->
<!-- segmentTypeID of 54 is Distributor PO Start -->
<scte35:SegmentationDescriptor segmentationTypeId="54"
segmentationEventId="99790150"
segmentNum="0" segmentsExpected="0">
<!-- upidType of 9 is a CableLabs ADI ID -->

10/21/16 CableLabs 101

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

<!-- UPID is hex encoding of SIGNAL:gFkRZZobSm+Nd7f5ccW1lA --

>
<scte35:SegmentationUpid segmentationUpidType="9"
segmentationUpidFormat="hexbinary"

>31302e353234302f444137332d333744442d313145372d393339342d444536442d55</scte35
:SegmentationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
</signal:ResponseSignal>
<!-- Condition the next 90 seconds of contents with 15 second segments
with 2 second fragments per segment -->
<!-- Each segment will have 7 two second fragments followed by a 1 one
second fragment -->
<!-- This pattern will be repeated until the overall duration of 90
seconds is reached -->
<signal:ConditioningInfo duration="PT1M30S">
<signal:Segment fragmentDuration="PT2S">PT15S</signal:Segment>
</signal:ConditioningInfo>
</signal:SignalProcessingNotification>

8.2.2.2.3 Delete current signal

The SPS instructs the SAS to delete the current signal because it was unable to confirm the
validity.
<signal:SignalProcessingNotification>
<!-- acquisitionSignalID - delete the splice insert message-->
<!-- GUID: 4A6A94EE-62FA-11E1-B1CA-882F4824019B -->
<!-- provide the signal point ID -->
<!-- GUID: 805911659a1b4a6f8d77b7f971c5b594== -->
<!-- Base64 representation: gFkRZZobSm+Nd7f5ccW1lA -->
<common:StatusCode classCode="0">
<core:Note>unconfirmed signal</core:Note>
</common:StatusCode>
<signal:ResponseSignal action="delete"
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
spsToken="spsToken1" sasToken="sasToken1"
acquisitionSignalID="4A6A94EE62FA11E1B1CA882F4824019B">
<sig:UTCPoint utcPoint="2006-05-04T18:13:51.0Z"/>
</signal:ResponseSignal>
</signal:SignalProcessingNotification>

8.2.2.2.4 Cancel existing signal

As described in Section 8.1.3, the SPS MAY instruct the SAS to repeat a signal every 5 seconds
for an extended duration. This is commonly used during blackout scenarios, but may have other
applications as well. When blackout alternative content is no longer required, the SPS sends a
cancel to the SAS ending the signal repetition. To cancel a previously confirmed content
identification signal, both the SAS and the SPS need to reference the acquisitionSignalId of the
previously confirmed signal. In other words, the systems need to be aware of the state of each
signal that has been confirmed.
The following use case replaces the previously repetitive content identification ResponseSignal
with a one-time content identification with a cancel indicator. In this use case, any downstream

102 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

system receiving the signal resulting from the updated ResponseSignal knows that the content
identification has ended based on explicit signaling.
<signal:SignalProcessingNotification
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
spsToken="spsToken1"
sasToken="sasToken1">
<!-- Cancel previously inserted repeating program identification signals
by replacing the previously sent ResponseSignal -->
<!-- GUID: 11b98ada-7cc0-4152-bc5c-1d2ab2909210 -->
<signal:ResponseSignal action="replace"
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="11b98ada7cc04152bc5c1d2ab2909210">
<sig:UTCPoint utcPoint="2012-09-18T10:00:05Z"/>
<scte35:SpliceInfoSection>
<!-- Time Signal Command -->
<scte35:TimeSignal>
<scte35:SpliceTime/>
</scte35:TimeSignal>
<!-- Segmentation descriptor -->
<!-- segmentTypeID of 1 is Content Identification -->
<scte35:SegmentationDescriptor segmentationTypeId="1"
segmentationEventId="99790150"
segmentationEventCancelIndicator="true" segmentNum="0"
segmentsExpected="0">
<!-- upidType of 10 is an EIDR -->
<!-- UPID is hex encoding of 10.5240/DA73-37DD-11E7-9394-
DE6D-U -->
<scte35:SegmentationUpid segmentationUpidType="10"
segmentationUpidFormat="hexbinary"

>31302e353234302f444137332d333744442d313145372d393339342d444536442d55</scte35
:SegmentationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
</signal:ResponseSignal>
</signal:SignalProcessingNotification>

An alternative implementation would be to send a delete referencing the acquisitionSignalID of

the ResponseSignal. Unlike the previous use case where there is explicit signaling, the
downstream implementation would need to detect loss of content identification signaling and
behave accordingly.
<signal:SignalProcessingNotification
<!-- Cancel previous inserted repeating program identification signals --
>
<!-- GUID: 11b98ada-7cc0-4152-bc5c-1d2ab2909210 -->
<common:StatusCode classCode="0">
<core:Note>unconfirmed signal</core:Note>
</common:StatusCode>
<signal:ResponseSignal action="delete"
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
spsToken="spsToken1" sasToken="sasToken1"
acquisitionSignalID="11b98ada-7cc04152bc5c1d2ab2909210">
<sig:UTCPoint utcPoint="2012-09-18T10:00:05Z"/>
</signal:ResponseSignal>
</signal:SignalProcessingNotification>

10/21/16 CableLabs 103

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Other alternatives that could be applied are to send a segmentation type id of "Program End"
(0x11) or "Program Breakaway" (0x13). See [SCTE 35] and [SCTE 67] for additional program
centric use cases.

8.2.2.2.5 Condition Stream for Downstream ABR Insertion

The SPS provides the SAS with duration information for a multi-spot break. The break below is
45 seconds long, composed of two spots of duration 30 and 15 seconds. The first segment starts
at PTS=4452723280 and the second follows immediately after the first (this would be PTS
4455423280 with corresponding UTCPoint 2006-05-04T18:14:26.0Z).
Conditioning information is provided for both spots using one ConditioningInfo element with
two segments.
<signal:SignalProcessingNotification
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
spsToken="spsToken1"
sasToken="sasToken1" signalProcessingIdentity="SignalProcessingSystem1">
<signal:ResponseSignal
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1" action="create"
acquisitionSignalID="SmqU7mL6EeGxyogvSCQBmw==" acquisitionTime="2006-
05-04T18:13:51.0Z"
signalPointID="gFkRZZobSm+Nd7f5ccW1lA==">
<sig:UTCPoint utcPoint="2006-05-04T18:13:56.0Z"/>
<sig:StreamTimes>
<sig:StreamTime timeType="PTS" timeValue="4452723280"/>
</sig:StreamTimes>
</signal:ResponseSignal>
<signal:ConditioningInfo duration="PT45S"
acquisitionSignalIDRef="SmqU7mL6EeGxyogvSCQBmw==">
<!-- conditioning for 30 second slot -->
<signal:Segment fragmentDuration="PT2S">PT30S</signal:Segment>
<!-- conditioning for the remaining 15 seconds -->
<signal:Segment fragmentDuration="PT2S">PT15S</signal:Segment>
</signal:ConditioningInfo>
</signal:SignalProcessingNotification>

8.2.2.2.6 Batch Conditioning Request for Downstream ABR Insertion

The SPS (ex. A VOD POIS) provides the SAS with NPT positional data for pre-roll, mid-roll
and post-roll insertion opportunities for a source file. The pre-roll is delineated by 2
signalPointID values, both with an NPT value of “BOS”. The mid-roll is delineated by 2
signalPointID values for the NPT range 732.537 to 792.537. The post-roll is delineated by 2
SignalPointID values for the end of the stream, “EOS” for both values.
This message can be sent from the SPS to the SAS or sent in response to a UriProcessingRequest
(see Section 7.1.2.6.2.1) from the SAS.
<signal:SignalProcessingNotification
acquisitionPointIdentity="VOD Processing_Point_1" spsToken="spsToken1"
sasToken="sasToken1" signalProcessingIdentity="VODSignalProcessingSystem1">
<!-- Batch information -->
<!-- TERSE DATA - MovieType allows lots of data about the asset -->
<common:BatchInfo batchId="27b777c1ee9941479677b56203953300">
<common:Source xsi:type="content:MovieType"

104 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

uriId="provider.com/Asset/UNVA2001081701004002">
<content:SourceUrl>The_Titanic.mpg</content:SourceUrl>
</common:Source>
<!-- Destination data can also be applied -->
</common:BatchInfo>
<!-- start of first region of interest - starts at BOS (NPT 0) -->
<signal:ResponseSignal action="create"
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="s/AhUqctQje0RpuvHAuvNQ=="
signalPointID="OjwgkQp4RwmdJc2u46vrmw==">
<sig:NPTPoint nptPoint="BOS"/>
<scte35:SpliceInfoSection>
<!-- Time Signal Command -->
<scte35:TimeSignal>
<scte35:SpliceTime/>
</scte35:TimeSignal>
<!-- Segmentation descriptor -->
<!-- segmentTypeID of 52 is Provider PO Start -->
<scte35:SegmentationDescriptor segmentationTypeId="52"
segmentNum="0"
segmentsExpected="0">
<!-- upidType of 9 is a CableLabs ADI ID -->
<!-- UPID is hex encoding of SIGNAL:OjwgkQp4RwmdJc2u46vrmw==
-->
<scte35:SegmentationUpid segmentationUpidType="9"
segmentationUpidFormat="hexbinary"

>5349474E414C3A4F6A77676B51703452776D644A633275343676726D773D3D</scte35:Segme
ntationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
</signal:ResponseSignal>
<!-- end of first region of interest - ends at BOS (NPT 0) -->
<signal:ResponseSignal action="create"
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="UR01sqCVSgydxKhzbQizyQ=="
signalPointID="mLSVqLc5RqKJGVAZ1LevaQ==">
<sig:NPTPoint nptPoint="BOS"/>
<scte35:SpliceInfoSection>
<!-- Time Signal Command -->
<scte35:TimeSignal>
<scte35:SpliceTime/>
</scte35:TimeSignal>
<!-- Segmentation descriptor -->
<!-- segmentTypeID of 53 is Provider PO END -->
<scte35:SegmentationDescriptor segmentationTypeId="53"
segmentNum="0"
segmentsExpected="0">
<!-- upidType of 9 is a CableLabs ADI ID -->
<!-- UPID is hex encoding of SIGNAL:mLSVqLc5RqKJGVAZ1LevaQ==
-->
<scte35:SegmentationUpid segmentationUpidType="9"
segmentationUpidFormat="hexbinary"

>5349474E414C3A6D4C5356714C633552714B4A4756415A314C657661513D3D</scte35:Segme
ntationUpid>
</scte35:SegmentationDescriptor>

10/21/16 CableLabs 105

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

</scte35:SpliceInfoSection>
</signal:ResponseSignal>
<!-- start of second region of interest - starts at NPT 732.537-->
<signal:ResponseSignal action="create"
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="4CFXb/7CRl6Q/8j6LyA8fw=="
signalPointID="Y8o0D3zpTxS0LT1ew+wuiw==">
<sig:NPTPoint nptPoint="732.537"/>
<scte35:SpliceInfoSection>
<!-- Time Signal Command -->
<scte35:TimeSignal>
<scte35:SpliceTime/>
</scte35:TimeSignal>
<!-- Segmentation descriptor -->
<!-- segmentTypeID of 52 is Provider PO Start -->
<scte35:SegmentationDescriptor segmentationTypeId="52"
segmentNum="0"
segmentsExpected="0">
<!-- upidType of 9 is a CableLabs ADI ID -->
<!-- UPID is hex encoding of SIGNAL:Y8o0D3zpTxS0LT1ew+wuiw==
-->
<scte35:SegmentationUpid segmentationUpidType="9"
segmentationUpidFormat="hexbinary"

>5349474E414C3A59386F3044337A70547853304C543165772B777569773D3D</scte35:Segme
ntationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
</signal:ResponseSignal>
<!-- end of second region of interest - ends at 792.537 -->
<signal:ResponseSignal action="create"
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="gIho/mMRTFefPKEOkDdP9w=="
signalPointID="6Wiqv1cCQumJctagOKS+ug==">
<sig:NPTPoint nptPoint="792.537"/>
<scte35:SpliceInfoSection>
<!-- Time Signal Command -->
<scte35:TimeSignal>
<scte35:SpliceTime/>
</scte35:TimeSignal>
<!-- Segmentation descriptor -->
<!-- segmentTypeID of 53 is Provider PO END -->
<scte35:SegmentationDescriptor segmentationTypeId="53"
segmentNum="0"
segmentsExpected="0">
<!-- upidType of 9 is a CableLabs ADI ID -->
<!-- UPID is hex encoding of SIGNAL:6Wiqv1cCQumJctagOKS+ug==
-->
<scte35:SegmentationUpid segmentationUpidType="9"
segmentationUpidFormat="hexbinary"

>5349474E414C3A365769717631634351756D4A637461674F4B532B75673D3D</scte35:Segme
ntationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
</signal:ResponseSignal>
<!-- start of third region of interest - starts at EOS-->

106 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

<signal:ResponseSignal action="create"
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="NKYoR2p7Sr6FTdCtXBcu4g=="
signalPointID="X1888YpLS/Sfma4CkVFOsg==">
<sig:NPTPoint nptPoint="EOS"/>
<scte35:SpliceInfoSection>
<!-- Time Signal Command -->
<scte35:TimeSignal>
<scte35:SpliceTime/>
</scte35:TimeSignal>
<!-- Segmentation descriptor -->
<!-- segmentTypeID of 52 is Provider PO Start -->
<scte35:SegmentationDescriptor segmentationTypeId="52"
segmentNum="0"
segmentsExpected="0">
<!-- upidType of 9 is a CableLabs ADI ID -->
<!-- UPID is hex encoding of SIGNAL:X1888YpLS/Sfma4CkVFOsg==
-->
<scte35:SegmentationUpid segmentationUpidType="9"
segmentationUpidFormat="hexbinary"

>5349474e414c3a583138383859704c532f53666d6134436b56464f73673d3d</scte35:Segme
ntationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
</signal:ResponseSignal>
<!-- end of third region of interest - ends at EOS -->
<signal:ResponseSignal action="create"
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="E6M9VPzaQFaEsahVDX305Q=="
signalPointID="2SLZcr1+QfqsYpSo0osuZw==">
<sig:NPTPoint nptPoint="EOS"/>
<scte35:SpliceInfoSection>
<!-- Time Signal Command -->
<scte35:TimeSignal>
<scte35:SpliceTime/>
</scte35:TimeSignal>
<!-- Segmentation descriptor -->
<!-- segmentTypeID of 53 is Provider PO END -->
<scte35:SegmentationDescriptor segmentationTypeId="53"
segmentNum="0"
segmentsExpected="0">
<!-- upidType of 9 is a CableLabs ADI ID -->
<!-- UPID is hex encoding of SIGNAL:2SLZcr1+QfqsYpSo0osuZw==
-->
<scte35:SegmentationUpid segmentationUpidType="9"
segmentationUpidFormat="hexbinary"

>5349474e414c3a32534c5a6372312b516671735970536f306f73755a773d3d</scte35:Segme
ntationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
</signal:ResponseSignal>
<!-- Condition contents with 15 second segments with 2 second fragments
per segment -->
<!-- Each segment will have 7 two second fragments followed by a 1 one
second fragment -->

10/21/16 CableLabs 107

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

<!-- This pattern will be repeated until the overall duration is reached
or the next signal point is encountered. -->
<signal:ConditioningInfo
acquisitionSignalIDRef="s/AhUqctQje0RpuvHAuvNQ==" duration="PT0S">
<signal:Segment fragmentDuration="PT2S">PT15S</signal:Segment>
</signal:ConditioningInfo>
<signal:ConditioningInfo
acquisitionSignalIDRef="4CFXb/7CRl6Q/8j6LyA8fw==" duration="PT60S">
<signal:Segment fragmentDuration="PT2S">PT15S</signal:Segment>
</signal:ConditioningInfo>
<signal:ConditioningInfo
acquisitionSignalIDRef="NKYoR2p7Sr6FTdCtXBcu4g==" duration="PT0S">
<signal:Segment fragmentDuration="PT2S">PT15S</signal:Segment>
</signal:ConditioningInfo>
</signal:SignalProcessingNotification>

The following is representative of feedback from an SAS for a URI process that has completed.
Not all information from the initial request is included but the NPT values are updated.
<SignalProcessingNotification acquisitionPointIdentity="VOD
Processing_Point_1" spsToken="spsToken1" sasToken="sasToken1"
signalProcessingIdentity="VODSignalProcessingSystem1">
<!-- Batch information -->
<!-- TERSE DATA - MovieType allows lots of data about the asset -->
<common:BatchInfo batchId="27b777c1ee9941479677b56203953300">
<common:Source xsi:type="content:MovieType"
uriId="provider.com/Asset/UNVA2001081701004002">
<content:SourceUrl>The_Titanic.mpg</content:SourceUrl>
</common:Source>
<!-- Destination data can also be applied -->
</common:BatchInfo>
<!-- start of first region of interest - starts at BOS (NPT 0) -->
<ResponseSignal
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="s/AhUqctQje0RpuvHAuvNQ=="
signalPointID="OjwgkQp4RwmdJc2u46vrmw=="
action="create">
<sig:NPTPoint nptPoint="BOS"/>
</ResponseSignal>
<!-- end of first region of interest - ends at BOS (NPT 0) -->
<ResponseSignal
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="UR01sqCVSgydxKhzbQizyQ=="
signalPointID="mLSVqLc5RqKJGVAZ1LevaQ=="
action="create">
<sig:NPTPoint nptPoint="BOS"/>
</ResponseSignal>
<!-- start of second region of interest - starts at NPT 732.537-->
<ResponseSignal
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="4CFXb/7CRl6Q/8j6LyA8fw=="
signalPointID="Y8o0D3zpTxS0LT1ew+wuiw=="
action="create">
<sig:NPTPoint nptPoint="732.622"/>
</ResponseSignal>
<!-- end of second region of interest - starts at NPT 792.537-->
<ResponseSignal

108 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="gIho/mMRTFefPKEOkDdP9w=="
signalPointID="6Wiqv1cCQumJctagOKS+ug=="
action="create">
<sig:NPTPoint nptPoint="792.539"/>
</ResponseSignal>
<!-- start of third region of interest - starts at NPT 998.456-->
<ResponseSignal
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="DAwH7EGuSsOVCEWfZWXmfA=="
signalPointID="xOUmk9UEQumkU/+OKvzW7g=="
action="create">
<sig:NPTPoint nptPoint="998.456"/>

</ResponseSignal>
<!-- end of third region of interest - starts at NPT EOS-->
<ResponseSignal
acquisitionPointIdentity="mso.com/VODProcessingPt/1"
acquisitionSignalID="QMNdRpfjQ6mwd0yhIeGaUw=="
signalPointID="/4jwRQSORLCdOvT+4d3MGg=="
action="create">
<sig:NPTPoint nptPoint="EOS"/>
</ResponseSignal>
</SignalProcessingNotification>

8.2.2.2.7 Alternate Content – Asynchronous slate notification

The SPS (ex. Blackout Control System) directs the SAS to put up a slate at a designed time.
Another SignalProcessingNotification message will be required at a future time to remove the
slate.
<signal:SignalProcessingNotification>
<signal:ResponseSignal action="create"
acquisitionPointIdentity="ESPN_East_HD"
acquisitionSignalID="4A6A94EE-62FA-11E1-B1CA-882F4824019B"
spsToken="spsToken1"
sasToken="sasToken1" signalPointID="10D65A82-631E-11E1-B5B7-
7A5A4824019B">
<sig:UTCPoint utcPoint="2013-07-06T10:14:34Z"/>
<signal:AlternateContent zoneIdentity="ESPN_East_HD_Z01"
altContentIdentity="ESPN_SLATE"/>
</signal:ResponseSignal>
</signal:SignalProcessingNotification>

8.2.2.2.8 Signal State Request Response – end point recovery

The SPS responds to a signal state request with all active signals for a given end point.
<SignalProcessingNotification
signalProcessingIdentity="SignalProcessingSystem1"
sasToken="SASToken1" spsToken="SPSToken1"
acquisitionPointIdentity="SignalAcquisitionSystem1">
<!-- The SCTE 35 binary includes: program end, program start and chapter
start. -->
<ResponseSignal action="create"
acquisitionPointIdentity="acquisitionPointIdentity0"
acquisitionSignalID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz0"

10/21/16 CableLabs 109

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz0">
<sig:UTCPoint utcPoint="2016-04-05T18:48:11Z"/>
<scte35:Binary signalType="SpliceInfoSection"

>/DDUAAAAAAAAAP/wBQb/AAAAAAC+AjpDVUVJAAAAAX+/DSsBATEJJlNJR05BTDpMeT
lFTUd4S1IwaEZaVXRwTUhkQ1VWWm5SVUZuWnowEQEBAj9DVUVJAAAAAn/XAAJAyEANKwEBMgkmU0l
HTkFMOkx5OUVNR3hLUjBoRlpVdHBNSGRDVVZablJVRm5aejEQAQECP0NVRUkAAAADf9cAAZv8wA0r
AQEyCSZTSUdOQUw6THk5RU1HeEtSMGhGWlV0cE1IZENVVlpuUlVGblp6MiABAVy6A/g=</scte35:
Binary>
</ResponseSignal>
<!-- The SCTE 35 binary includes: chapter end, provider placement
opportunity start, and provider advertisement start -->
<ResponseSignal action="create"
acquisitionPointIdentity="acquisitionPointIdentity0"
acquisitionSignalID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz3"
signalPointID="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz3">
<sig:UTCPoint utcPoint="2016-04-05T18:53:11Z"/>
<scte35:Binary signalType="SpliceInfoSection"

>/DC1AAAAAAAAAP/wBQb/AAAAAACfAjpDVUVJAAAAA3+/DSsBATIJJlNJR05BTDpMeT
lFTUd4S1IwaEZaVXRwTUhkQ1VWWm5SVUZuWnozIQEBAjpDVUVJAAAABH//AACky4AJJlNJR05BTDp
MeTlFTUd4S1IwaEZaVXRwTUhkQ1VWWm5SVUZuWno0NAEBAiVDVUVJAAAABX//AABSZcANEQEBMgMM
Y21jYTExMTExMTExMAEB42I6tw==</scte35:Binary>
</ResponseSignal>
<!-- The SCTE 35 binary includes: provider advertisement end,
distributor placement Opportunity start, and provider advertisement start -->
<ResponseSignal action="create"
acquisitionPointIdentity="acquisitionPointIdentity0"
acquisitionSignalID="cmca11111111" signalPointID="cmca11111111">
<sig:UTCPoint utcPoint="2016-04-05T18:54:11Z"/>
<scte35:Binary signalType="SpliceInfoSection"

>/DCbAAAAAAAAAP/wBQb/AAAAAACFAiBDVUVJAAAABX+/DREBATIDDGNtY2ExMTExMT
ExMTEBAQI6Q1VFSQAAAAZ//wAAUmXACSZTSUdOQUw6THk5RU1HeEtSMGhGWlV0cE1IZENVVlpuUlV
Gblp6NjYBAQIlQ1VFSQAAAAd//wAAUmXADREBATIDDGNtY2ExMTExMTExMjABAaj9Cw0=</scte35
:Binary>
</ResponseSignal>
<ConditioningInfo
acquisitionSignalIDRef="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz0"/>
<ConditioningInfo
acquisitionSignalIDRef="Ly9EMGxKR0hFZUtpMHdCUVZnRUFnZz3"/>
<ConditioningInfo acquisitionSignalIDRef="cmca11111111"/>
</SignalProcessingNotification>

110 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

9 MANIFEST CONFIRMATION AND CONDITIONING API

The manifest confirmation and conditioning API is for use between an ABR fragmenter and the
manifest confirmation and conditioning service. The fragmenter provides a manifest
confirmation by sending an HTTP POST request with the defined JSON or XML payload and it
receives conditioning information in the response's payload. Alternatively the fragmenter may be
provisioned with a template response for the conditioning information.
The manifest confirmation input parameters provide as much information as possible regarding
the signal point triggering the confirmation. An example signal point may be a splice out/exit
point as indicated by an SCTE 35 splice_info_section()/splice_insert() command or it could be
an SCTE 35 segmentation_descriptor().
The return payload provides information about how the fragmenter might condition the ABR
stream and associated manifest files, and it provides auxiliary data to be inserted for downstream
signal point identification.
The manifest API supports two different forms of HLS manifest conditioning: media segment
modification mode (segment modify) and media segment replacement mode (segment replace).
The fragmenter submits the same input payload to an endpoint URL and receives the appropriate
response.
Media segment modification mode, i.e., segment modify, describes the output manifest changes
when only a subset of the HLS media segments are enhanced.
Media segment replacement mode, i.e., segment replace, indicates the API returned a set of
media segments that are to directly replace an existing region of media segments.
Each mode has its positives and negatives and the selection and usage are outside the scope of
this document.
If the caller does not support a returned attribute's usage, the attribute is to be ignored. For
example, if the caller does not support the Microsoft Smooth sparse track/fragment insertion, the
attribute is ignored.

9.1 Manifest Conditioning Use Cases

The following use cases are meant as a guideline for defining the schemas for the event and
notification elements and are not intended to be an exhaustive representation of the system
usage. The schemas are designed with extensibility features that are intended to support yet-to-
be-defined signaling models and formats.
9.1.1 Smooth conditioning for ads insertion
The fragmenter generates a ManifestConfirmConditionEvent element containing one or more
confirmed signals and forwards it to the SPS endpoint. The SPS responds with a
ManifestConfirmConditionNotification message, which carries the payload to be inserted into the
appropriate sparse tracks.

10/21/16 CableLabs 111

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

9.1.2 HLS conditioning for ads insertion

The fragmenter generates a ManifestConfirmConditionEvent element containing one or more
confirmed signals and forwards it to the SPS endpoint. The SPS responds with a
ManifestConfirmConditionNotification message, which carries the instructions on how to
manipulate the appropriate segments with the HLS manifest.
9.1.3 Conditioning for blackouts
The fragmenter generates a ManifestConfirmConditionEvent element containing one or more
confirmed signals and forwards it to the SPS endpoint. The SPS responds with a
ManifestConfirmConditionNotification message, which carries security metadata and optionally
a payload to be inserted into the appropriate sparse tracks.
9.1.4 Support multi-format conditioning
The fragmenter generates a ManifestConfirmConditionEvent element containing one or more
confirmed signals and in the StreamTime element indicates the required format. The SPS
responds with a ManifestConfirmConditionNotification message, which carries manifest
conditioning instructions for all the requested formats.

9.1.5 Support VOD processing

The fragmenter can generate a ManifestConfirmConditionEvent which contains all of the
confirmed signals that MAY be present in a VOD asset. The SPS responds with a
ManifestConfirmConditionNotification message, which carries manifest conditioning
instructions for all the requested formats.

9.2 Manifest Confirmation and Conditioning API Messages

9.2.1 ManifestConfirmConditionEvent
The following XML payload is submitted to the endpoint URI:

Figure 37 - ManifestConfirmConditionEvent XML Schema

112 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 38 - AcquiredSignal XML Schema

10/21/16 CableLabs 113

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

9.2.1.1 ManifestConfirmConditionEvent Semantics

Semantics for the manifest confirmation and condition events are the same as acquired signal
(See section 8.2.1).

9.2.1.2 ManifestConfirmConditionEvent Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:scte35="http://www.scte.org/schemas/35/2016"
xmlns:sig="urn:cablelabs:md:xsd:signaling:3.0"
xmlns:manifest="urn:cablelabs:iptvservices:esam:xsd:manifest:1"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

9.2.1.2.1 SCTE 35 SpliceInsert

The fragmenter forwards an SCTE 35 splice insert marker to the POIS using the following
syntax.
<manifest:ManifestConfirmConditionEvent>
<manifest:AcquiredSignal spsToken="spsToken0" sasToken="sasToken0"
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="4A6A94EE-62FA-11E1-B1CA-882F4824019B"
acquisitionTime="2013-11-19T10:14:34Z">
<sig:UTCPoint utcPoint="2012-09-18T10:14:34Z"/>
<scte35:SpliceInfoSection>
<scte35:SpliceInsert spliceEventId="344568691"
outOfNetworkIndicator="true"
uniqueProgramId="55355">
<scte35:Program>
<scte35:SpliceTime ptsTime="4452723280"/>
</scte35:Program>
<scte35:BreakDuration autoReturn="false" duration="60"/>
</scte35:SpliceInsert>
</scte35:SpliceInfoSection>
<sig:StreamTimes>
<sig:StreamTime timeType="PTS" timeValue="4452723280"/>
<sig:StreamTime timeType="HLS" timeValue="4452723280"/>
</sig:StreamTimes>
</manifest:AcquiredSignal>
</manifest:ManifestConfirmConditionEvent>

9.2.1.2.2 SCTE 35 TimeSignal

The fragmenter forwards an event for an ad marker defined with SCTE 35 TimeSignal using the
following syntax:
<manifest:ManifestConfirmConditionEvent>
<manifest:AcquiredSignal spsToken="spsToken0" sasToken="sasToken0"
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="4A6A94EE-62FA-11E1-B1CA-882F4824019B"
acquisitionTime="2013-11-19T10:14:34Z">
<sig:UTCPoint utcPoint="2012-09-18T10:14:34Z"/>
<scte35:SpliceInfoSection>
<scte35:TimeSignal>

114 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

<scte35:SpliceTime ptsTime="4452723280"/>
</scte35:TimeSignal>
<scte35:SegmentationDescriptor segmentationEventId="344568691"
segmentationDuration="60" segmentationTypeId="50"
segmentNum="0" segmentsExpected="0">
<scte35:SegmentationUpid segmentationUpidType="9"
segmentationUpidFormat="hexbinary">784B7944684C70786779455764446950596A78</sc
te35:SegmentationUpid>
</scte35:SegmentationDescriptor>
</scte35:SpliceInfoSection>
<sig:StreamTimes>
<sig:StreamTime timeType="PTS" timeValue="4452723280"/>
<sig:StreamTime timeType="HLS" timeValue="4452723280"/>
</sig:StreamTimes>
</manifest:AcquiredSignal>
</manifest:ManifestConfirmConditionEvent>

9.2.1.2.3 SCTE 35 Binary

The fragmenter forwards an unparsed SCTE 35 event in binary format to the POIS:
<manifest:ManifestConfirmConditionEvent>
<manifest:AcquiredSignal spsToken="spsToken0" sasToken="sasToken0"
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="4A6A94EE-62FA-11E1-B1CA-882F4824019B"
acquisitionTime="2013-11-19T10:14:34Z">
<sig:UTCPoint utcPoint="2012-09-18T10:14:34Z"/>
<scte35:Binary
signalType="SpliceInfoSection">/DDUAAAAAAAAAP/wBQb/AAAAAAC+AjpDVUVJAAAAAX+/DS
sBATEJJlNJR05BTDpMeTlFTUd4S1IwaEZaVXRwTUhkQ1VWWm5SVUZuWnowEQEBAj9DVUVJAAAAAn/
XAAJAyEANKwEBMgkmU0lHTkFMOkx5OUVNR3hLUjBoRlpVdHBNSGRDVVZablJVRm5aejEQAQECP0NV
RUkAAAADf9cAAZv8wA0rAQEyCSZTSUdOQUw6THk5RU1HeEtSMGhGWlV0cE1IZENVVlpuUlVGblp6M
iABAVy6A/g=</scte35:Binary>
<sig:StreamTimes>
<sig:StreamTime timeType="PTS" timeValue="4452723280"/>
<sig:StreamTime timeType="HLS" timeValue="4452723280"/>
</sig:StreamTimes>
</manifest:AcquiredSignal>
</manifest:ManifestConfirmConditionEvent>

10/21/16 CableLabs 115

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

9.2.2 ManifestConfirmConditionNotification
The following response XML payload is returned:

Figure 39 - ManifestConfirmConditionNotification XML Schema

116 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 40 - ManifestResponse XML Schema

10/21/16 CableLabs 117

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 41 - SegmentModify XML Schema

Figure 42 - SegmentReplace XML Schema

118 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Figure 43 - SparseTrack XML Schema

Figure 44 - SpliceCueInfo XML Schema

10/21/16 CableLabs 119

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Figure 45 - TemplateResponse XML Schema

9.2.2.1 ManifestConfirmConditionNotification Semantics

If the fragmenter does not recognize or support the returned attribute/element or its semantics,
then the fragmenter is to ignore the data.
Table 44 - ManifestConfirmConditionNotification Elements

Name Required Description

ManifestResponse Y See Section 9.2.2.2
Status Code O See Section 6.1

Table 45 - ManifestConfirmConditionNotification Attributes

Name Required Description

signalProcessingIdentity C Signal processing identity SHALL be specified on
asynchronous messages. Signal processing identity
SHOULD be specified when responding to a signal
processing event
acquisitionPointIdentity O A unique identity of the acquisition point identifying the
signal acquisition system (ex. transcoder) at a specific
site on a specific channel/network feed for all of the
contained ResponseSignal or AlternateContentEvent
elements.
spsToken C Optional token that uniquely identifies this response. If
the spsToken was passed in the registration message, the
SPS SHALL pass the same token in this request.
sasToken C Optional token that uniquely identifies the SAS
registration. If it was passed in the SAS registration
message it SHALL be passed in this message.

9.2.2.2 ManifestResponse Semantics

If the fragmenter does not recognize or support the returned attribute/element or its semantics,
then the fragmenter is to ignore the data.

120 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Table 46 - ManifestResponse Attributes

Name Required Description

acquisitionPointIdentity Y A required string, typically a system-wide unique string,
identifying the transcoder at a specific site on a specific
channel/network feed.

acquisitionSignalID Y A required string, typically a GUID, generated by the
transcoder identifying the signal point being confirmed.
spsToken C Optional token that uniquely identifies this response. If
the spsToken was passed in the registration message, the
SPS SHALL pass the same token in this request.
sasToken C Optional token that uniquely identifies the SAS
registration. If it was passed in the SAS registration
message it SHALL be passed in this message.
signalPointID O Optional string generated by the SPS identifying the
confirmed signal.
dataPassThrough O Optional Boolean value that indicates if the data needs to
be forwarded unmodified to the downstream systems. For
example, in HLS applications if this parameter is true,
then the fragmenter will pass the SCTE 35 signal in the
data PID of the transport stream.
duration O Optional UTC encoded signal region (e.g., break/avail)
duration. See Section 6.3 for additional format
information.

10/21/16 CableLabs 121

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Table 47 - ManifestResponse Elements

Name Required Description

SegmentModify O The returned object when the manifest file is to be altered in
media segment modify mode. In media segment modify
mode, only a limited set of media segments are altered. The
first media segment associated with the signal starting MAY
be modified, zero or more "middle" media segments MAY be
altered, and the last media segment of a region MAY be
enhanced. That is, the splice exit/out media segment MAY be
updated (i.e., signal start point), the splice return/in media
segment MAY be altered (i.e., signal region end), and if the
optional spanSegment object is present, each media segment
following the first media segment is modified until the last
media segment is encountered. The spanSegment information
assists when a signal region spans two or more manifest files.
This object is typically only used for live event manifest
generation. VOD manifest files are expected to be self-
contained and SHOULD NOT use the spanSegment object.
For clarification, the use of SegmentModify does not entail
modifying the associated URI but rather modifying the media
tags only. With that, the media tags in question are bound by
the duration of the event signal in the request message.
A spanSegment object typical use is in scenarios where an
"exit" from the network tagged in the conditioned manifest is
in the past of a live stream and a downstream consumer of the
conditioned manifest must be made aware by further tagging
of the media segments.
SegmentReplace O One or more media segments (i.e., a JSON segments array
entry or an XML Segment element) to replace the existing
media segments starting at the signal point thru the end of the
signal region. Both the extinf attribute and the uri attribute
SHALL be present in each media segment. The extinf
attribute supplies data for the media segment starting
"#EXTINF" tag line. The uri attribute is used as the media
segment's URI component. Each media segment is
substituted for an existing media segment in sequence.
SparseTrack O Optional data to be embedded in an ABR Microsoft Smooth
sparse track. The data blob is an adaptable string similar to
the tags/value attribute.
SpliceCueInfo O Optional container for one or more HDS Cue elements. See
[F4M].
SecurityMetadata O Optional security data to provide instructions for encryption
key rotations and/or data to be forwarded downstream.

122 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Name Required Description

TemplateResponse O Optional: Indicates that this response is a template response.
The template MAY be used with an SCTE 35 message to
create the manifest conditioning for the SCTE 35 message.

9.2.2.2.1 SegmentModify Semantics

Table 48 - SegmentModify Elements

Name Required Description

FirstSegment O One or more manifest lines that are inserted at the signal
point start media segment (i.e., the signal splice start
location). The media segment's start record marker (i.e.,
#EXTINF line) and URI are not altered.
If the signal region duration (as signaled in
ManifestResponse@duration) is zero, the manifest lines are
inserted before the media segment immediately following the
signal point, and all Tags SHALL have a (possibly implicit)
locality of "before".
Tag element: See Section 9.2.2.3.
SpanSegment O Optional and typically only used in live streaming mode. One
or more manifest lines that are inserted for each media
segment between the first media segment and the last media
segment, excluding the first and last media segments, which
are independently specified using the firstSegment and
lastSegment objects.
Tag element: See Section 9.2.2.3.
LastSegment O Optional manifest lines that are inserted with the last media
segment identified as the end location. The media segment's
start record marker (i.e., #EXTINF line) and URI are not
altered.
If the signal region duration (as signaled in
ManifestResponse@duration) is zero, the manifest lines are
inserted after the media segment immediately preceding the
signal point, and all Tags SHALL have a locality of "after".
Tag element: See Section 9.2.2.3.

9.2.2.2.2 SegmentReplace Semantics

Table 49 - SegmentReplace Elements

Name Required Description

Segment Y A single media segment consisting of the extinf attribute, a
URI, and zero or more tag lines.

10/21/16 CableLabs 123

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

9.2.2.2.2.1 Segment Semantics

Table 50 - Segment Attributes

Name Required Description

duration O Optional ISO duration. See Section 6.3 for additional format
information.
extinf O The #EXTINF line data which the fragmenter is to append to
the string "#EXTINF:" which is assumed to be provided by
the fragmenter. Thus, a common attribute value is "8," and
the fragmenter outputs "#EXTINF:8," for the media segment.
Uri O The URI to be adapted by the fragmenter and inserted as the
URI component of a manifest record. Every URI attribute
value is to be modified by the fragmenter before placement
into the manifest file using the substitution keywords defined
in Section 9.2.2.3.

Table 51 - Segment Elements

Name Required Description

Tag O The manifest tag lines to be inserted. See Section 9.2.2.3 for
additional information.

9.2.2.2.3 SparseTrack Semantics

Table 52 - SparseTrack Attributes

Name Required Description

trackName O Optional track name identifier. If omitted, the first sparse
track is to be assumed.
value O Required string placed into the Smooth sparse track. Section
9.2.2.3 contains the substitution keyword and description
table.

9.2.2.2.4 Template Response Semantics

Table 53 - Template Response Attributes

Name Required Description

validDuration O Optional ISODuration type which indicates for how long
this template response is valid. After the duration expires,
the packager will call out to the POIS upon receipt of the
next SCTE 35 message. If not present, the template will
always be valid.

124 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Name Required Description

templateType O Optional string that indicates to what type of SCTE 35
message this template can be applied. If this value is not
present, the template will be applied to all SCTE 35
messages. Valid values are in Table 54.

Table 54 - TemplateType Attribute Values

Value Description
NETWORK_OUT The template will be applied if the SCTE 35 message
indicates a network out condition.
NETWORK_IN The template will be applied if the SCTE 35 message
indicates a network in condition.
ANY The template will be applied to all SCTE 35 messages.
PRIVATE: Custom type attribute.

Table 55 - TemplateType for Segmentation Types

Segmentation Message Segmentation_type_id Template Type

Not Indicated 0x00 N/A
Content Identification 0x01 N/A
Program Start 0x10 NETWORK_OUT
Program End 0x11 NETWORK_IN
Program Early Termination 0x12 NETWORK_IN
Program Breakaway 0x13 NETWORK_IN
Program Resumption 0x14 NETWORK_OUT
Program Runover Planned 0x15 NETWORK_IN
Program Runover Unplanned 0x16 NETWORK_IN
Program Overlap Start 0x17 NETWORK_OUT
Program Blackout Override 0x18 NETWORK_IN
Program Start – In Progress 0x19 NETWORK_OUT
Chapter Start 0x20 NETWORK_OUT
Chapter End 0x21 NETWORK_IN
Provider Advertisement Start 0x30 NETWORK_OUT
Provider Advertisement End 0x31 NETWORK_IN
Distributor Advertisement Start 0x32 NETWORK_OUT
Distributor Advertisement End 0x33 NETWORK_IN
Provider Placement Opportunity Start 0x34 NETWORK_OUT

10/21/16 CableLabs 125

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Segmentation Message Segmentation_type_id Template Type

Provider Placement Opportunity End 0x35 NETWORK_IN
Distributor Placement Opportunity Start 0x36 NETWORK_OUT
Distributor Placement Opportunity End 0x37 NETWORK_IN
Unscheduled Event Start 0x40 NETWORK_OUT
Unscheduled Event End 0x41 NETWORK_IN
Network Start 0x50 NETWORK_OUT
Network End 0x51 NETWORK_IN

9.2.2.2.4.1 Template Semantics

The TemplateResponse will be able to use macro substitutions in the ManifestResponse which
instruct the packager about how to condition the manifests using the SCTE 35 message as a
source. These macros are delimited by the '$' character in the notification response. Here is a
list of the possible macros along with the origin of the data for that macro. If a specified macro
element is not present in the SCTE 35 message, that element of the notification SHOULD be
ignored.
acquisitionPointIdentity Configured on the packager
acquisitionSignalID Randomly generated per signal
segmentationEventId Extracted from segmentation_event_id in the segmentation descriptor
segmentationTypeId Extracted from segmentation_type_id in the segmentation descriptor
segmentationUpid Extracted from segmentation_upid() name in the segmentation
descriptor
duration Extracted from segmentation_duration in the segmentation descriptor
hdsDuration Duration expressed as fractional seconds
availNum Extracted from splice insert command or segment num in the
segmentation descriptor
availExpected Extracted from splice insert command or segments expected in the
segmentation descriptor
subSegmentNum Extracted from the sub_segment_num in the segmentation descriptor
subSegmentsExpected Extracted from the sub_segments_expected in the segmentation
descriptor
utcPoint Expected wall clock time of signal point in UTC timestamp (XML
dateTime)
ptsTime Expected PTS value of signal point
smoothTime Expected Smooth timestamp of signal point
hdsTime Expected signal point time expressed as fractional seconds
binarySignal Base64 encoded representation of the SCTE 35 signal

126 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

9.2.2.3 Tag Semantics

Tag (XML sequence)—One or more manifest tags (lines) to be directly inserted into the output
manifest file. Each line is explicitly controlled, via the "adapt" attribute, as to whether the line
element is to be placed directly into the manifest file unaltered or if the fragmenter is to enhance
the returned attribute value. If the line is to be altered/enhanced by the fragmenter prior to
placement into the manifest file, the "adapt" attribute is set to the "true" value. The fragmenter
fills in the placeholder substitution keyword framed by the start substitution delimiter '${' and
ending delimiter '}'. Thus, the full substitution sequence is ${keyword}. Table 56 lists the
substitution keywords and their descriptions. The line insertion location is controlled by the
"locality" attribute and lines having the same locality are positioned in returned document order.
Table 56 - Manifest Line Substitution Keywords

Substitution Keyword Value Description

timeFromSignal Offset from the CUE (typically a start segmentation type) of
the earliest presentation time of the HLS media segment that
follows.
If an implementation removes fragments from the manifest file
(ex. live application), the ELAPSED value SHALL be adjusted
by the duration of the media segments removed.
Elapsed is expressed in seconds to millisecond accuracy
formatted as an ISODuration. See section 6.3
timeFromSignalFS Offset from the CUE (typically a start segmentation type) of
the earliest presentation time of the HLS media segment that
follows.
If an implementation removes fragments from the manifest file
(ex. live application), the ELAPSED value SHALL be adjusted
by the duration of the media segments removed.
Elapsed is expressed in seconds to millisecond accuracy. (ex.
30.234)
segmentID The original media segment URI.
streamID The configured streamId value.

Table 57 - Tag Attributes

Name Required Description

adapt O Optional Boolean indicating if the value attribute's string is to be
modified by the fragmenter before placement into the manifest file. If
the attribute is omitted, the default value is "false."
locality O Optional string specifying the line location relative to the media
segment. Table 58 lists the possible values along with a location
description. The attribute values SHALL appear exactly as they do in
Table 58. If the attribute is omitted, the default value is "before".

10/21/16 CableLabs 127

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Name Required Description

value O Required string, typically starting with "#EXT", placed into the
manifest file.

Table 58 - locality Attribute

Value Description
before The line is to be placed before the media segment's #EXTINF tag line.
within The line is to be placed in between the media segment's start #EXTINF
line and the media segment's ending URI line.
after The line is to be placed after the media segment's URI line.

9.2.2.4 Notification Examples

To improve readability, all XML schemas in this section are assumed to have the following
namespace declaration:
xmlns:core="urn:cablelabs:md:xsd:core:3.0"
xmlns:scte35="http://www.scte.org/schemas/35/2016"
xmlns:sig="urn:cablelabs:md:xsd:signaling:3.0"
xmlns:manifest="urn:cablelabs:iptvservices:esam:xsd:manifest:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

9.2.2.4.1 HLS Segment compliant with SCTE 35

This is an example of a template consistent with SCTE 35 usage in HLS (see [SCTE 35]). It uses
FirstSegment exclusively for network out and in.
<manifest:ManifestConfirmConditionNotification >
<manifest:ManifestResponse dataPassThrough="false">
<manifest:SegmentModify>
<manifest:FirstSegment>
<manifest:Tag locality="before"
value="#EXT-X-
SCTE35:TYPE=$segmentationTypeId$,CUE=$binarySignal$,ELAPSED=${timeFromSignalS
tartFS}"
/>
</manifest:FirstSegment>
</manifest:SegmentModify>
<manifest:TemplateResponse templateType="NETWORK_OUT"/>
</manifest:ManifestResponse>
<manifest:ManifestResponse dataPassThrough="false">
<manifest:SegmentModify>
<manifest:FirstSegment>
<manifest:Tag locality="before"
value="#EXT-X-
SCTE35:TYPE=$segmentationTypeId$,CUE=$binarySignal$"/>
</manifest:FirstSegment>
</manifest:SegmentModify>
<manifest:TemplateResponse templateType="NETWORK_IN"/>
</manifest:ManifestResponse>
</manifest:ManifestConfirmConditionNotification>

128 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

9.2.2.4.2 HLS Segment Modify

<manifest:ManifestConfirmConditionNotification>
<manifest:ManifestResponse
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="4A6A94EE-62FA-11E1-B1CA-882F4824019B"
signalPointID="10D65A82-631E-11E1-B5B7-7A5A4824019B"
duration="PT1M0S"
dataPassThrough="true">
<manifest:SegmentModify>
<manifest:FirstSegment>
<manifest:Tag value="#EXT-X-SPLICE-EXIT:
SpliceDescriptors=0x786df876dffa87687"/>
<manifest:Tag value="#EXT-X-DISCONTINUITY"/>
</manifest:FirstSegment>
<manifest:SpanSegment>
<manifest:Tag adapt="true" value="#EXT-X-SPLICE-SPAN:

SpliceDescriptors=0x786df876dffa87687,TimeFromSignal=${timeFromSignal}"/>
</manifest:SpanSegment>
<manifest:LastSegment>
<manifest:Tag adapt="true" value="#EXT-X-SPLICE-
SPAN:SpliceDescriptors=0x786df876dffa87687,TimeFromSignal=${timeFromSignal}"/
>
<manifest:Tag locality="after" value="#EXT-X-SPLICE-
RETURN:SpliceDescriptors=0x786df876dffa87687"/>
<manifest:Tag locality="after" value="#EXT-X-DISCONTINUITY"/>
</manifest:LastSegment>
</manifest:SegmentModify>
</manifest:ManifestResponse>
</manifest:ManifestConfirmConditionNotification>

9.2.2.4.3 HLS Segment Replace

<ManifestConfirmConditionNotification>
<manifest:ManifestResponse
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="4A6A94EE-62FA-11E1-B1CA-882F4824019B"
signalPointID="10D65A82-631E-11E1-B5B7-7A5A4824019B"
duration="PT1M0S"
dataPassThrough="true">
<manifest:SegmentReplace>
<manifest:Segment extinf="10,"
uri="http://ADMServer/decisions?segment=${segmentID}&amp;spliceDescriptors=0x
00085448495300112233&amp;net=CNN&amp;time=2010-12-17T11:12:42.123Z">
<manifest:Tag value="#EXT-X-SPLICE-
EXIT:spliceDescriptors=0x00085448495300112233"/>
<manifest:Tag value="#EXT-X-DISCONTINUITY"/>
</manifest:Segment>
<manifest:Segment extinf="10,"
uri="http://ADMServer/decisions?segment=${segmentID}&amp;spliceDescriptors=0x
00085448495300112233&amp;net=CNN&amp;time=2010-12-17T11:12:42.123Z"/>
<manifest:Segment extinf="10,"
uri="http://ADMServer/decisions?segment=${segmentId}&amp;spliceDescriptors=0x
00085448495300112233&amp;net=CNN&amp;time=2010-12-17T11:12:42.123Z">
<manifest:Tag locality="after" value="#EXT-X-SPLICE-
RETURN:spliceDescriptors=0x00085448495300112233"/>

10/21/16 CableLabs 129

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

<manifest:Tag locality="after" value="#EXT-X-DISCONTINUITY"/>

</manifest:Segment>
</manifest:SegmentReplace>
</manifest:ManifestResponse></ManifestConfirmConditionNotification>

9.2.2.4.4 HSS Sparse Track

<ManifestConfirmConditionNotification>
<ManifestResponse
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="4A6A94EE-62FA-11E1-B1CA-882F4824019B">
<SparseTrack
trackName="ad_marker">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPEF
jcXVpcmVkU2lnbmFsIHhtbG5zPSJodHRwOi8vd3d3LmNvbWNhc3QuY29tL3NjaGVtYXMvTkdPRC9T
aWduYWwvMjAxMC9SMVYwIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZ
W1hLWluc3RhbmNlIiB4c2k6c2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cuY29tY2FzdC5jb20vc2
NoZW1hcy9OR09EL1NpZ25hbC8yMDEwL1IxVjAgQ0MtTkdPRC1TSUdOQUxJTkctUjFWMC0xMDEyMTA
ueHNkIj4KCTxBY3F1aXNpdGlvblBvaW50SW5mbyBBY3F1aXNpdGlvblBvaW50SWRlbnRpdHk9IkUh
Q01DU0EzIiBBY3F1aXNpdGlvblNpZ25hbElEPSI1YjQ4ZjdmZi1hMTJlLTQ0ZWEtOGIxZC1iODA5O
GZjZDEwZmEiLz4KCTxVVENPZlN3aXRjaFBvaW50IFVUQ1BvaW50PSIyMDEyLTAyLTI5VDIxOjE5Oj
A5WiIvPgoJPFN0cmVhbVRpbWVzPgoJCTxTdHJlYW1UaW1lIFRpbWVUeXBlPSJTbW9vdGgiIFRpbWV
WYWx1ZT0iMjM3NTk0NDAxMDg4OCIvPgoJCTxTdHJlYW1UaW1lIFRpbWVUeXBlPSJQVFMiIFRpbWVW
YWx1ZT0iNDIwMzYyNjkxNCIvPgoJPC9TdHJlYW1UaW1lcz4KPC9BY3F1aXJlZFNpZ25hbD4K
</SparseTrack>
</ManifestResponse>
</ManifestConfirmConditionNotification>

9.2.2.4.5 HSS Blackout (with Key Rotation)

<ManifestConfirmConditionNotification>
<ManifestResponse
acquisitionPointIdentity="ESPN_East_Acquisition_Point_1"
acquisitionSignalID="4A6A94EE-62FA-11E1-B1CA-882F4824019B">
<SparseTrack
trackName="ad_marker">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPEF
jcXVpcmVkU2lnbmFsIHhtbG5zPSJodHRwOi8vd3d3LmNvbWNhc3QuY29tL3NjaGVtYXMvTkdPRC9T
aWduYWwvMjAxMC9SMVYwIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZ
W1hLWluc3RhbmNlIiB4c2k6c2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cuY29tY2FzdC5jb20vc2
NoZW1hcy9OR09EL1NpZ25hbC8yMDEwL1IxVjAgQ0MtTkdPRC1TSUdOQUxJTkctUjFWMC0xMDEyMTA
ueHNkIj4KCTxBY3F1aXNpdGlvblBvaW50SW5mbyBBY3F1aXNpdGlvblBvaW50SWRlbnRpdHk9IkUh
Q01DU0EzIiBBY3F1aXNpdGlvblNpZ25hbElEPSI1YjQ4ZjdmZi1hMTJlLTQ0ZWEtOGIxZC1iODA5O
GZjZDEwZmEiLz4KCTxVVENPZlN3aXRjaFBvaW50IFVUQ1BvaW50PSIyMDEyLTAyLTI5VDIxOjE5Oj
A5WiIvPgoJPFN0cmVhbVRpbWVzPgoJCTxTdHJlYW1UaW1lIFRpbWVUeXBlPSJTbW9vdGgiIFRpbWV
WYWx1ZT0iMjM3NTk0NDAxMDg4OCIvPgoJCTxTdHJlYW1UaW1lIFRpbWVUeXBlPSJQVFMiIFRpbWVW
YWx1ZT0iNDIwMzYyNjkxNCIvPgoJPC9TdHJlYW1UaW1lcz4KPC9BY3F1aXJlZFNpZ25hbD4K
</SparseTrack>
<SecurityMetadata>
z4KPEFjcXVpcmVkU2lnbmFsIHhtbG5zPSJodHRwOi8vd3d3LmNvbWNhc3QuY29tL3NjaGVtYXMvTk
dPRC9TaWduYWwvMjAxMC9SMVYwIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEv
</SecurityMetadata>
</ManifestResponse>
</ManifestConfirmConditionNotification>

130 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

10 DEPENDANT SCHEMAS AND APIS

10.1 CableLabs MD Signaling Schema

The XML schema for signal processing and conditioning SHALL be the CableLabs MD
Signaling Schema version 3.0 ([CONTENT 3.0]). Originating systems SHALL use the
SignalProcessingEvent element to send events to the processing system, while processing
systems SHALL use the SignalProcessingNotification to represent the notification payload.

10.1.1 StreamTimes
The StreamTimes object SHALL carry one or more native stream time values. There SHALL be
at least one stream time entry when present.
The XML schema SHALL be a sequence of one or more of the following:

Figure 46 - StreamTime XML Schema

10.1.1.1 StreamTime type Semantics

Table 59 - StreamTime Type Semantics Attributes

Name Required Description

timeType O A value exactly as it appears from Table 60.
timeValue O The native format time value encoding of the signal point
(e.g., the splice time or cue time) as specified in Table 61.

10/21/16 CableLabs 131

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Table 60 - timeType Attribute Values

Value Description
DASH MPEG DASH
HLS Apple HTTP Live Streaming
NPT Normal Play Time
PTS MPEG-2 Transport Stream
HSS Microsoft HTTP Smooth Streaming (HSS)
HDS Adobe HTTP Dynamic Streaming
(HDS/Zeri)
SignalID CableLabs Metadata 3.0 Signal ID
private:* Add extensibility

Table 61 - timeValue Formats

Identifier Description
DASH Time in 90 KHz clock ticks. The MPEG PTS value.
HLS Time in 90 KHz clock ticks. The MPEG PTS value.
NPT TBD
PTS Time in 90 KHz clock ticks. The MPEG PTS value.
HSS Time in hundred nanosecond units.
HDS Time in seconds dot ('.') decimal fractional second.
SignalID Value passed as coded in the CableLabs metadata. The value
MAY be a GUID, base64 encoded GUID or other value.
private:* extensibility

10.2 CableLabs MD Content Schema

The XML schema for content SHALL be the CableLabs MD Content Schema version 3.0
([CONTENT 3.0]). When dealing with URI sourced material (see Section 7.1.2.6), the
MovieType element SHALL be used to identify and describe the source and destination content.

132 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

11 EXAMPLE SIGNALING DIAGRAMS

The messages described throughout this section can be sent or received synchronously or
asynchronously. In order to provide additional clarity regarding this concept, the following
example signaling flows have been provided.

11.1 In-band Signaling Example

In the following example, the content provider provides an in-band SCTE 35 mark signaling a
necessary change to alternate content for an upcoming time and duration, among other details.
Upon receiving the in-band signal, the transcoder sends a SignalProcessingEvent to the Signal
Processor (e.g., POIS). The Signal Processor responds with a synchronous
SignalProcessingNotification, which MAY include instructions to modify or replace the in-band
signal. The signal is sent downstream to the fragmenter, which sends a
ManifestConfirmConditionEvent to the Signal Processor, which responds with a synchronous
ManifestConfirmConditionNotification.

Signal Signal
Content Acquisition Signal Acquisition
Provider (Transcoder) Processor (Fragmenter)
MPEG2-TS
SCTE-35
Signal Processing Event
HTTP Post
Signal Processing Notification
HTTP Response
ABR Video
SCTE-35
Manifest Conf.
Cond. Event
Manifest Conf.
Cond. Notification

Figure 47 - In-band Signaling Example

11.2 Out-of-band Signaling Example

In the following example, the content provider notifies the content distributor of an upcoming
necessary change to alternate content along with the time and duration, among other details.
Prior to the specified time, the Signal Processor sends an asynchronous
SignalProcessingNotification to the transcoder. The transcoder inserts the appropriate signal
within the video. The signal is sent downstream to the fragmenter, which sends a

10/21/16 CableLabs 133

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

ManifestConfirmConditionEvent to the Signal Processor, which responds with a

ManifestConfirmConditionNotification.

Signal Signal
Content Acquisition Signal Acquisition
Provider (Transcoder) Processor (Fragmenter)

Out-of-band signaling

Signal Processing Notification

HTTP Post
MPEG2-TS

ABR Video
SCTE-35
Manifest Conf.
Cond. Event
Manifest Conf.
Cond. Notification

Figure 48 - Out-of-band Signaling Example

134 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

11.3 Out-of-band Manifest Conditioning Example

In the following example, the content provider notifies the content distributor of an upcoming
necessary change to alternate content along with the time and duration, among other details. At
the specified time, the Signal Processor sends an asynchronous
ManifestConfirmConditionNotification to the fragmenter. After receiving the notification, the
fragmenter modifies the manifest or sparse track appropriately.

Signal Signal
Content Acquisition Signal Acquisition
Provider (Transcoder) Processor (Fragmenter)

Out-of-band signaling

MPEG2-TS
Manifest Conf.
Cond. Notification
ABR Video

Figure 49 - Out-of-band Manifest Conditioning Example

10/21/16 CableLabs 135

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Annex A ESAM Normative Schemas

The messages, elements, and attributes that make up this specification are not explicitly defined
in this document. The XML schemas, provided separately, are a normative part of this
specification and SHALL be adhered to.
No messages representing the interfaces defined in the schema are considered conformant unless
they are valid according to the schema documents. In the case where the written normative
specification and the normative schema document conflict, the specification SHALL take
precedence. Furthermore, there are additional requirements described in the schema annotations
that are not enforceable by schema validation mechanisms. These requirements SHALL also be
strictly observed.
The inclusion of a normative XML schema document does not require or imply the specific use
of the schema nor a requirement that a message be validated.

A.1 ESAM Common Schema

The normative version of the ESAM Common schema file is published as a part of this release
with the name OC-SP-ESAM-API-C01-Common.xsd.

A.2 ESAM Signal Schema

The normative version of the ESAM Signal schema file is published as a part of this release with
the name OC-SP-ESAM-API-C01-Signal.xsd.

A.3 ESAM Manifest Schema

The normative version of the ESAM Manifest schema file is published as a part of this release
with the name OC-SP-ESAM-API-C01-Manifest.xsd.

136 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

Appendix I Acknowledgements
We wish to thank the participants contributing directly to this document:
Arris: Guy Cherry
Elemental Technologies: Jesse Rosenzweig
Envivio: Alex MacAulay
Comcast: Allen Broome, Tedd Dawson, Francesco Dorigo, Kevin Flanagan, and Walt Michel
Time Warner Cable: Chuck Hasek
CableLabs: David Agranoff, Don Burt, and Daryl Malas

10/21/16 CableLabs 137

OC-SP-ESAM-API-C01-161021 OpenCable™ Specifications

Appendix II Revision History

The following ECNs were incorporated into version I02 of this specification:

Accepted
ECN Identifier Author Description
Date

ESAM-API-N- Michel 4/4/2013 Add support for batch processing (e.g., VOD
13.1821-2 Content) and element recovery

ESAM-API-N- Agranoff 9/3/2013 Update Metadata references

13.1856-2

ESAM-API-N- Agranoff 9/3/2013 Clarify transmission of SignalPointID between

13.1857-2 Transcoder and Packager/Fragmenter

ESAM-API-N- Agranoff 9/3/2013 Clarification of LastSegment and guidelines for

13.1858-1 inserting a new signal at transcoder

ESAM-API-N- McBride 9/3/2013 Add support for template response to manifest

13.1859-1 confirmation API

ESAM-API-N- Flanagan 9/27/2013 Linear Stream Switching Interface

13.1860-1

ESAM-API-N- Agranoff 9/27/2013 Additional Schema changes

13.1865-1

The following ECN was incorporated into version I03 of this specification:

Accepted
ECN Identifier Author Description
Date

ESAM-API-N- Agranoff 10/25/13 Fixes for ESAM Signaling Schema

13.1868-2

138 CableLabs 10/21/16

Event Signaling and Management API OC-SP-ESAM-API-C01-161021

The following ECNs were incorporated into version C01 of this specification:

Accepted
ECN Identifier Author Description
Date

ESAM-API-N- Michel 4/25/14 Unbound ManifestResponse in

13.1869-1 ManifestConfirmConditionNotification

ESAM-API-N- Michel 7/5/16 ESAM I03 update

16.1883-2

10/21/16 CableLabs 139