SCTE-35: Cue Messages, Timing & SSAI Handoffs | Callaba

SCTE-35 carries timed event messages alongside video. Those messages can mark an ad opportunity, a return to programme, a blackout boundary or another distribution event. They are instructions and metadata, not the replacement video itself. A reliable workflow must preserve the cue's identity and timing, interpret it under an agreed policy, and prove what every downstream system did with it.

A cue crosses several systems before a viewer sees a result

SCTE-35 signals an opportunity; it does not choose the replacement

The official SCTE 35-1 standard defines in-stream messages for insertion and other distribution events. Its scope explicitly leaves the insertion method and replacement constraints to other systems. This separation matters: a syntactically valid cue cannot prove that an ad decision server returned an eligible asset or that a packager built a playable break.

Assign separate owners for cue origination, transport, interpretation, decisioning, stitching and playback. Define the correlation key for the selected profile. It may use splice_event_id, segmentation_event_id, the SCTE 35-2 EventDescriptor or a controlled composite of identity and timing fields; there is no universal command event ID for every message. Without an agreed join key, teams compare unrelated timestamps and mislabel the mismatch as a timing problem.

Choose SCTE 35-1 or the current SCTE 35-2 event model deliberately

SCTE 35-1 2023r2 contains the legacy splice-based and time-based models, including familiar splice_insert() and time_signal() combinations. The current SCTE 35-2 2026 adds a streamlined EventDescriptor to TimeSignal, recommends TimeDescriptor and describes that event form as a replacement for SCTE 35-1 integrations.

Do not mix both models implicitly. A 35-1 contract might correlate a segmentation_event_id, segmentation type, presentation time, duration and cancel state. A 35-2 contract should retain its EventDescriptor identity, event semantics, TimeDescriptor where used and the same start, update or return interpretation through the receiver. Record the selected standard edition in configuration and fixtures so a packager rewrite cannot silently change the event model.

Understand commands, descriptors and the event timeline

In a 35-1 workflow, a cue may use a splice command such as splice_insert() or time_signal(), with descriptors adding segmentation meaning for downstream policy. A 35-2 workflow uses the constrained event model above. The correct interpretation depends on the declared standard and integration profile, not on one field copied into a dashboard.

For each expected event, capture arrival time, presentation time, the selected correlation key, type, duration when present, programme or avail context, cancellation and explicit return behaviour. Check whether the cue is immediate or scheduled against the media timebase. Do not convert everything to wall-clock time and discard the original presentation relationship.

Preservation must be tested at every transformation

Demultiplexing, transcoding, remultiplexing and packaging can change the container around the cue. A pass-through assumption is unsafe whenever a component rebuilds transport metadata or timestamps. Before production, inject a controlled set of start, return, duration and cancel events, then compare decoded values before and after each transforming hop.

The SCTE 67 recommended practice highlights timing and monitoring concerns around cue messages. Preserve enough raw evidence to distinguish an absent cue from a present cue whose timing or descriptor semantics changed.

HLS and DASH need explicit signalling contracts

A transport-stream cue is not automatically useful to an HTTP player or server-side stitcher. The packager must map the event into the delivery format and profile expected by the next system. SCTE 35-2 points implementers to SCTE 214-1 carriage guidance and HLS carriage rules; a deployment still needs to name the exact HLS or DASH profile it implements. Document its tag or event representation, how the selected correlation key survives mapping, and what happens when a break spans a manifest update.

Fetch the viewer-facing manifest during the event, not only the origin input. Verify the signalled start, duration, discontinuity behaviour and segment sequence around both entry and return. If personalization is used, repeat the check for more than one decision outcome.

Build one event fixture across transport, package and decision

For a 35-1 fixture, select a TimeSignal plus segmentation descriptor, controlled segmentation_event_id, start presentation time, duration and matching return or cancel behaviour. For a 35-2 fixture, select TimeSignal plus EventDescriptor, TimeDescriptor where the integration uses it, a controlled event identity and the same timing outcomes. The two fixtures should remain separate.

Decode the source transport and save the selected fields. At the packager, record the exact configured HLS or DASH carriage profile and save the corresponding output representation rather than assuming a tag name. At decisioning, record which correlation key and timing were received. Then inspect entry, chosen replacement, exit and resumed programme. A cancel fixture should produce the declared cancellation outcome at every later boundary, not merely disappear from one log.

Timing quality depends on media boundaries as well as cue fields

A cue can name an exact presentation time while the video cannot switch cleanly there. Encoder keyframes, segment boundaries, conditioning rules and downstream tolerance affect the visible result. Define whether the workflow promises frame-accurate switching, segment-aligned replacement or a bounded deviation, then measure that promise.

Use synchronized clocks for cross-system logs, but retain media timestamps too. Wall-clock evidence helps correlate services; presentation timestamps explain the relationship between the cue and frames. A useful incident record includes both.

Commission the complete break, including failure paths

1. Define an event matrix. Include normal start and return, duration-based events, cancellation, overlapping or late events and a missing replacement asset.
2. Decode at boundaries. Save safe structured evidence at origin input, post-processing output, packager and viewer manifest.
3. Correlate decisions. Join cue identity to request, response, chosen asset, stitched segments and playback result.
4. Inspect media. Check keyframes, audio continuity, captions, alternate audio, timestamps and the programme return.
5. Set fallback policy. Decide whether a failed decision keeps programme, uses slate, uses a house ad or ends the break early.
6. Alert on outcomes. Distinguish cue missing, cue late, decision timeout, asset rejection, stitch error and playback failure.