Signaling service
The Signaling Service is provided as a service and can be integrated into any existing content management workflow through its APIs, enabling seamless adoption without significant changes to your current setup.
Developed and provided by THEO Technologies, this service operates on your infrastructure, integrated between your CDN and media origin. It performs manifest manipulation to insert ad breaks and additional metadata for the player. Additionally, it ensures scalability of the end-to-end system through early ad break notifications to ad decisioning servers.
Infrastructure integration
The service is deployed and operated by THEO Technologies within the customer’s infrastructure. This setup ensures smooth integration into the existing video workflow with minimal disruption. During onboarding, THEO Technologies provides the specific infrastructure and network requirements. Once set up, THEO Technologies bootstraps the service, after which the customer can manage their streams and monitor the service through the REST API.
In collaboration with the customer and THEO's solutions team, the integration of the service into the existing video workflow is designed. Deploying the Signaling Service between the CDN and Origin ensures that regionalization, security, and localization features remain unaffected.
To ensure high availability, we recommend maintaining the original origin stream on a CDN as a backup, while the Signaling Service provides redundancy and failover capabilities to further enhance reliability.
Monetized streams
After deployment of the Signaling Service has been completed, the next step is the creation of monetized streams. A monetized stream represents an instance of a origin stream that is processed by the Signaling Service to enable THEOads for this origin stream. Created via the locally deployed REST API, it exposes a standardized HTTPS (or HTTP) endpoint for the CDN to fetch the augmented manifest. This setup ensures seamless ad insertion without needing CDN reconfiguration, even if the monetized stream is stopped and recreated.
The monetized stream holds the following information:
streamId
: Unique identifier for the monetized stream within the environment.name
: Self defined descriptive name for the monetized stream.description
: Optional descriptive information for the monetized stream.labels
: Array of self defined labels (string).layout
: Default experience layout, see ad experience layout.origin
: Your media origin host.segmentOrigin
: Your publicly available segments origin host.assetKey
: Google DAI Asset-Key linked to this stream, see Google DAI.networkCode
: Google DAI Network-Code, see Google DAI.assetURI
: Optional custom asset URI which is to be used during ad breaks. If not set it will request an adbreak through Google Pod Serving.backdropURI
: Optional URI containing the back-drop to be used during the double box or L-shape ad.
{
"streamId": "theoads-demo",
"name": "THEOads Demo",
"description": "SGAI THEOads Demo",
"labels": [],
"layout": "DOUBLE",
"origin": "https://domain.com",
"segmentOrigin": "https://segment-domain.com",
"assetKey": "google-sgai-demo",
"networkCode": "89053",
"assetURI": "https://asset.m3u8",
"backdropURI": "https://backdrop.svg"
}
Creating a new monetized stream
The following API endpoint creates a new monetized stream, mandatory parameters are:
streamId
: Unique identifier for the monetized stream within the environment.name
: Self defined descriptive name for the monetized stream.description
: Optional descriptive information for the monetized stream.layout
: Default experience layout, see ad experience layout.origin
: Your media Origin host.segmentOrigin
: Your publicly available segments origin.assetKey
: Google DAI Asset-Key representing the stream, see Google DAI.networkCode
: Google DAI Network-Code, see Google DAI.
curl -L 'https://<theoads-host>/ads-client/api/v1/monetized-streams' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
"streamId": "string",
"name": "string",
"description": "string",
"layout": "SINGLE",
"origin": "string",
"segmentOrigin": "string",
"assetKey": "string",
"networkCode": "string"
}'
Updating an existing monetized stream
The following API endpoint updates an existing monetized stream based on it's streamId, mandatory parameters are:
streamId
: Unique identifier for the monetized stream within the environment.name
: Self defined descriptive name for the monetized stream.description
: Additional descriptive information for the monetized stream.labels
: Array of self defined labels (string).layout
: Default experience layout, see ad experience layout.origin
: Your media Origin host.segmentOrigin
: Your publicly available segments origin.assetKey
: Google DAI Asset-Key representing the stream, see Google DAI.networkCode
: Google DAI Network-Code, see Google DAI.
curl -L -X PATCH 'https://<theoads-host>/ads-client/api/v1/monetized-streams/:streamId' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
"streamId": "string",
"name": "string",
"description": "string",
"labels": [
"string"
],
"origin": "string",
"segmentOrigin": "string",
"assetKey": "string",
"networkCode": "string"
}'
Deleting an existing monetized stream
The following API endpoint deletes an existing monetized stream based on it's streamId.
curl -L -X DELETE 'https://<theoads-host>/ads-client/api/v1/monetized-streams/:streamId' \
-H 'Accept: application/json'
Retrieving all monetized streams
The following API endpoint returns all existing monetized streams in the deployed environment.
curl -X 'GET' \
'https://<theoads-host>/ads-client/api/v1/monetized-streams' \
-H 'accept: application/json'
The response is an array of the existing monetized stream resources.
[
{
"id": "theoads-demo",
"payload": {
"streamId": "theoads-demo",
"name": "THEOads Demo",
"description": "SGAI THEOads Demo",
"labels": [],
"layout": "DOUBLE",
"origin": "https://domain.com",
"segmentOrigin": "https://segment-domain.com",
"assetKey": "google-sgai-demo",
"networkCode": "89053"
},
"state": "created",
"type": "monetized-stream"
}
]
Retrieving an individual monetized stream
The following API endpoint returns an existing monetized stream based on its identifier (streamId).
curl -L 'https://<theoads-host>/ads-client/api/v1/monetized-streams/:streamId' \
-H 'Accept: application/json'
The response is the monetized stream resource.
{
"id": "theoads-demo",
"payload": {
"streamId": "theoads-demo",
"name": "THEOads Demo",
"description": "SGAI THEOads Demo",
"labels": [],
"layout": "DOUBLE",
"origin": "https://domain.com",
"segmentOrigin": "https://segment-domain.com",
"assetKey": "google-sgai-demo",
"networkCode": "89053"
},
"state": "created",
"type": "monetized-stream"
}
Please refer to the API reference for even more detailed information on the REST API.
Player source
When playing a THEOads source corresponding to a monetized stream, it is expected to pass a source that looks like this:
src: 'https://<theoads-host>/signaling-service/api/v1/<monetized-stream-id>/hls/MANIFEST-URI';
In this URI, the <theoads-host>
points to the network endpoint where the THEOads service is deployed, preferably a DNS entry pointing to the service IP endpoint and reachable from the CDN.
Secondly, the <monetized-stream-id>
corresponds to the streamId
for the monetized stream.
Finally, the MANIFEST-URI
part points to the origin's manifest relative to the configured origin
property of the monetized stream.
For example:
src: 'https://<theoads-host>/signaling-service/api/v1/<monetized-stream-id>/hls/manifest.m3u8';
Segment URLs in the media playlists should be absolute URLs however.
Segment requests don't need to pass through the Signaling Service but should be fetched directly from the CDN to the origin so as to keep the benefit of scaling via the CDN.
The segmentOrigin
parameter should contain this publicly available endpoint to fetch the segments directly.
Scheduling ad breaks
Once all the required monetized streams are configured, the next step is scheduling ad breaks for these monetized streams.
To accurately schedule breaks, the origin manifest must be valid and include date and time indications.
For HLS, this means the EXT-X-PROGRAM-DATE-TIME
tag must be present.
Ad breaks can be signaled through either the provided REST API or by including the relevant information in the manifest itself.
Manifest
When using manifest signaling, the following tags are supported:
#EXT-X-DATERANGE
tag- this is recommended because of its standardization and ability to provide more comprehensive data for improved integration.
#EXT-X-OATCLS-SCTE35
tag#EXT-X-CUE-OUT
and#EXT-X-CUE-OUT-CONT
tags- To use the tune-in feature,
#EXT-X-CUE-OUT-CONT
tags must be present between#EXT-X-CUE-OUT
and#EXT-X-CUE-IN
markers.
Optionally, SCTE markers can be included with the tags for extra metadata.
REST API
For scheduling ad breaks through the REST API, please refer to the API definitions and the example below.
curl --location 'https://<theoads-host>/ads-client/api/v1/monetized-streams/stream-1/break' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
"id": "626cd35a-4fbf-48b8-b0cd-acc246266f88",
"startDate": "2024-09-03T08:00:00.000Z",
"duration": 60,
"source": "",
"layout": "LSHAPE_AD"
}'
For more in depth information on scheduling ad breaks we refer to our How-to guide: Scheduling breaks
For more information on this topic we refer to our workflow integration.