Third-party HLS delivery
Use a proven Callaba origin behind Akamai—not an assumed native integration
Akamai can distribute live or on-demand segmented media from a customer origin. In the workflow covered here, Callaba receives and processes the programme, exposes a validated HLS presentation through a dedicated TLS origin hostname, and Akamai Adaptive Media Delivery fetches and caches that presentation for viewers. Akamai is a separately contracted and configured system; a Callaba deployment does not create an Akamai property for you.
The architecture in one line
Encoder → SRT or RTMP contribution → Callaba ingest, optional transcoding, and HLS origin → Akamai Adaptive Media Delivery property → application or browser player.
SRT ends at the contribution receiver; a CDN does not turn it into browser playback. Callaba must first produce a coherent HLS presentation. Akamai then handles the separately defined origin, cache, property-hostname, access-protection, and edge-delivery contract. Start with standard HLS. Validate low-latency HLS as a separate phase because enabling an Akamai low-latency behavior does not convert an ordinary HLS origin into an LL-HLS origin.
The moving marker illustrates a request crossing the ownership boundaries. It is not an Akamai cache-hit indicator or live Callaba telemetry, and it stops for reduced-motion users.
Assign three owners before opening either control plane
Callaba owner
Owns contribution, source health, any decode/transcode, HLS packaging or Web Player output, origin capacity, media continuity, and the TLS endpoint that Akamai is permitted to fetch.
Akamai owner
Owns the licensed Adaptive Media Delivery property, origin and host-header settings, certificate verification, caching and cache key, property activation, token protection, reports, and Akamai support escalation.
Application owner
Owns viewer identity and entitlement, token issuance and refresh, player integration, supported devices, CORS where needed, real-user QoE, and the customer-visible incident path.
One person may hold several roles, but the evidence must stay separate. A healthy Callaba source does not prove an edge cache. A high cache-offload rate does not prove that a viewer can decode the audio. A valid token does not prove the entitlement decision was correct.
Preflight: collect the real endpoint contract
- Callaba: source type, output URL path, master and media playlists, segment format, codecs, audio groups, captions, target duration, update cadence, origin hostname, TLS certificate, expected edge request rate, and recovery source.
- Akamai: product entitlement, contract or property name, property hostname, edge hostname, origin hostname, forward host header, TLS verification mode, live or on-demand mode, cache-key policy, access-protection method, staging and production activation owners.
- Application: playback hostname, player and device cohorts, CORS origin, authentication flow, token location and lifetime, refresh behavior, analytics, error taxonomy, and rollout cohort.
Build standard HLS delivery in eight controlled steps
- Prove the contribution in Callaba. Receive one representative source through the appropriate Callaba product—commonly ingest and routing. Confirm the session and transport evidence, then watch moving picture and listen to every required audio track. Do not configure Akamai around a source that has not passed locally.
- Create the viewer-ready media contract. Use live video transcoding only when the source does not already match the approved ladder, codec, GOP, audio, or caption requirements. For file-based delivery, use the Video on Demand workflow. Validate the complete HLS presentation with the adaptive HLS player procedure.
- Put the origin behind a dedicated TLS name. Configure DNS, certificate, virtual host, and firewall or access policy so Akamai can retrieve the approved media paths. Test the master playlist, every referenced media playlist, initialization segment when present, ordinary segments, audio, and captions over that hostname.
- Keep presentation URLs on the delivery path. Resolve relative URLs against the expected property hostname and inspect any absolute URLs. A playlist that points segments back to the Callaba origin bypasses Akamai for those requests and reveals the origin. Fix the origin output or an approved Akamai rule; do not rely on a player-specific accident.
- Create or update the Akamai AMD property. In Property Manager, select the customer-origin option documented as Your Origin, enter the exact origin hostname, set the required forward host header, and configure origin TLS verification so the certificate name and trust policy match. Do this with the Akamai account owner; available behavior versions and permissions depend on the contract.
- Set the media mode deliberately. Use Akamai's Segmented Media Delivery Mode for Live on a live HLS path and On Demand on immutable VOD content. Akamai documents that these modes adjust manifest TTL behavior. A broad manual cache rule can override those optimizations, so review child rules and match criteria before activation.
- Stage before production. Associate the property hostname and edge hostname, install the viewer-facing certificate, activate on the Akamai staging network, and test with the intended host mapping and player. Then promote the same reviewed property version to production through the team's change process.
- Ramp a real cohort. Start with internal probes, then a small viewer percentage or one event class. Compare Callaba source/origin evidence, Akamai Traffic and Origin Performance reports, and player startup, failure, rebuffer, and rendition telemetry on one synchronized timeline.
Cache playlists and segments according to their lifecycle
| Object | Lifecycle | Main risk | Acceptance evidence |
|---|---|---|---|
| Live master playlist | Changes when renditions or groups change; often more stable than media playlists. | A stale version hides a new rendition, audio group, caption, or failover path. | Fetch through the property hostname before and after a controlled change; verify the expected version reaches the player. |
| Live media playlist | Advances continuously with new sequence entries. | Excessive freshness lifetime freezes the live edge; no cache or wrong key can overload the origin. | Observe advancing media sequence and playable new segments from more than one edge region. |
| Live media segment | Should normally be immutable once published at a unique path. | Reusing a URL for different bytes creates corruption or stale content; under-caching drives avoidable origin load. | Compare repeated delivery, byte stability, edge/offload trend, and playback across a rendition switch. |
| VOD playlist and segment | Stable after publication unless the asset is replaced. | Replacing bytes at the same URL makes invalidation and client caches ambiguous. | Publish versioned paths, test cold and warm delivery, seek, subtitles, audio selection, and an intentional replacement. |
| Token-bearing request | Authorization state changes independently of the media bytes. | Putting every unique token in the media cache key destroys sharing; ignoring a value that changes authorization or content can expose or mix responses. | Test two authorized users, a denied user, expiry, refresh, logout, key rotation, and cache behavior without logging secrets. |
Akamai documents that cache rules can honor or override origin Cache-Control and Expires headers and that cache-key changes can produce an origin request spike. Review the active rule tree, not only one UI panel. Do not copy TTLs or query-parameter exclusions from another property whose content lifecycle and authorization model are different.
Low-latency HLS has an additional gate
Akamai's current AMD documentation says low-latency HLS uses a third-party origin and requires a specific property rule: Live mode with low-latency support enabled, HLS content characteristics, HTTPS/HTTP/2, and cache-key handling for the special _HLS query parameters. It also distinguishes discrete parts from byte-range parts.
Those edge settings are only half of the contract. The Callaba origin and player must already produce and consume a conforming LL-HLS presentation with partial segments and the required playlist behavior. Do not enable the Akamai option on a standard HLS output and promise a latency number. First capture the exact origin playlist, confirm supported part mode, measure glass-to-glass latency and rebuffering on every target cohort, and retain a standard-HLS fallback.
Protect access without breaking cache behavior
Viewer authorization should begin with an application entitlement decision and end with Akamai validating the approved request credential. Akamai supports Auth Token 2.0, and its current documentation recommends Segmented Media Protection for Adaptive Media Delivery where available. The available mechanism, token location, path scope, signing algorithm, key rotation, and player behavior belong to the Akamai and application contracts.
Test the master playlist and every child request. A token accepted on the first URL is not useful if relative playlist, segment, audio, caption, or key requests lose it. Conversely, do not place signing secrets in Callaba page content, browser code, URLs captured in public logs, or screenshots. Use HTTPS viewer-to-edge and verified TLS edge-to-origin. Keep dashboard and management APIs off the media hostname.
An acceptance plan that can identify the failed owner
Origin correctness
Probe the master and every referenced object through the origin hostname. Verify status, MIME type, TLS, stable segment bytes, playlist advance, audio, captions, and CORS for the actual player origin.
Cold and warm edge delivery
Run an initial request and repeated requests from representative regions. Compare Akamai Traffic and Origin Performance with Callaba origin load; do not infer cache behavior from player success alone.
Playback cohorts
Measure first frame, join failure, rebuffer, quality switches, live-edge distance, audio continuity, caption selection, and end-to-end recovery on each supported browser, app, and device class.
Access lifecycle
Verify allow, deny, expiry during playback, silent refresh, logout, shared-link attempt, clock skew, and signing-key transition. Redact credentials from evidence.
Origin failure
Interrupt a controlled origin dependency and observe edge, player, and operator behavior. Serving a stale live playlist can look available while the programme is frozen; define acceptable continuity explicitly.
Rollback
Restore the last known Callaba output, Akamai property version, DNS association, and player configuration independently. Record who can activate each rollback and how long evidence takes to appear.
Troubleshoot by request path
- The origin plays, but the property hostname returns an error
- Compare the Akamai origin hostname, forward host header, DNS, port, certificate trust and name, and path. Reproduce the same host header against the authorized origin before changing the encode.
- The master loads, but playback fails
- Open every referenced media playlist, segment, init segment, audio, caption, and key URL through the property hostname. Look for origin-bypassing absolute URLs, CORS, token propagation, MIME types, and codec mismatch.
- Viewers stay behind live
- First confirm that the Callaba media playlist advances correctly. Then inspect AMD Live mode, overriding cache rules, player live-edge policy, and regional origin performance. A CDN cannot make a stale origin playlist current.
- Origin load grows with audience
- Separate playlists from immutable segments, inspect cache keys and token uniqueness, review no-store or short-lifetime headers, and use Akamai reports to find the URLs driving origin traffic before changing capacity.
- Only authenticated playback fails
- Compare entitlement output, token scope/location/time, child-request propagation, edge verification result, and player refresh. Do not disable verification as the production fix.
Primary technical references
- Akamai: HLS and a third-party origin — current LL-HLS origin, rule, cache-key, HTTP/2, and part-mode requirements.
- Akamai Property Manager: Origin Server — origin hostname, forward host header, cache-key hostname, TLS verification, and ports.
- Akamai: Segmented Media Delivery Mode — Live and On Demand media modes and manifest TTL behavior.
- Akamai caching documentation — origin cache headers, Property Manager rules, TTL, purge, and cache conflicts.
- Akamai: Auth Token 2.0 Verification — token locations, HMAC configuration, expiry, key transition, and AMD protection guidance.
- Akamai: View reports for AMD — Traffic, Origin Performance, geography, hostname, and URL reporting.
- RFC 8216: HTTP Live Streaming — playlist, rendition, media-segment, sequence, and client behavior.
Product first, API after the delivery path passes
Start in the Callaba UI and follow the Web Players guide to prove one presentation. For general CDN architecture, use the video CDN guide; this section focuses on handing a validated origin to Akamai. Once one output survives origin, edge, authorization, device, and failure tests, use the Web Players API to reproduce known Callaba objects. Akamai property automation remains a separate Akamai-controlled workflow.
Prove the origin before scaling the audience
Launch one representative Callaba output, verify every HLS object on the dedicated origin hostname, then onboard that exact path to an Akamai staging property. Promote only when Callaba, Akamai, and player evidence agree on the same run.
