Global Edge CDN

A global edge network built to keep live streams moving.

Each viewer is routed to a nearby healthy edge based on location, availability, and current load. TCP Boost improves compatible standard playback without client changes, while CloudTV RXT provides a more resilient path for enabled applications on difficult networks.

Discuss your delivery routeExplore common workflows
Live-first delivery
Built for continuous live playback
Per-viewer routing
Location · Edge availability · Current load
CloudTV PlatformGlobal live route
Routes · Origins · Edge health · Access · Usage
World map representing CloudTV edge coverage across major global regions Los Angeles viewer
Best available edgeLos AngelesNearby · Healthy · 28% load
Live sourceCustomer origin or Live Media Core
Traffic steeringLocation · Availability · Current load
Viewer pathsStandard player · TCP BoostRXT-enabled application · CloudTV RXT

Real-world delivery

Start with the playback problem your audience already sees.

Bring a regional source closer to a global audience, strengthen the final playback path, or add access controls and delivery visibility without replacing the origin and players you already operate.

01 · Global audience

Take a regional live source to a global audience.

When one origin serves viewers across countries and continents.

A regional origin may be reliable for nearby viewers but leave an international audience on long network paths. Sending everyone to one fixed edge cannot adapt when edge health and load change.

Publish through a standard protocol, let CloudTV pull the origin, use an RXT-enabled publishing path, or connect a Live Media Core output. Once the source enters the network, each viewer is directed to a nearby healthy edge based on location, availability, and current load.

Best suited to Global live platforms and OTT services, broadcasters, sports and event streams, product launches, and education or meeting services with audiences in several regions.
Source optionsStandard publishOrigin pullRXT-enabled publishLive Media Core
Global edge networkPer-viewer route selectionLocation · Availability · Current load
PlaybackBest available edgeDifferent viewers can use different edges
02 · Standard playback

Make standard live playback more resilient without rebuilding the player.

When the route after the edge still cannot sustain the live bitrate.

Using a CDN shortens the route, but the connection from the selected edge to the viewer can still encounter latency, packet loss, congestion, or unstable throughput. General-purpose delivery may complete a file download without keeping a continuous live stream free from buffering.

TCP Boost improves compatible standard TCP playback from the CloudTV edge. The viewer keeps the existing browser, player, application, and playback protocol; no RXT integration is required.

Best suited to Live platforms with existing players and applications, web playback, standard OTT clients, international audiences with unstable playback, and services that cannot immediately rebuild the viewer client.
  1. Live source
  2. Best available CloudTV edge
  3. TCP Boost
  4. Existing browser, player, or application
03 · RXT-enabled playback

Keep playback moving when standard transport is no longer enough.

When viewers face more severe latency, packet loss, or network variation.

Some playback paths remain unable to sustain the required live bitrate even after the stream reaches a nearby edge. This is more common across countries, continents, restricted routes, and unstable access networks.

When you control the application or device, Native SDK & Applications can enable CloudTV RXT between the selected edge and the playback endpoint. Standard protocols remain available for viewers that do not use an RXT-enabled client.

Best suited to Live services with their own applications, cross-border and intercontinental viewing, remote education and meetings, professional devices, and audiences whose networks are substantially more difficult than a normal internet path.
  1. Live source
  2. Selected CloudTV edge
  3. CloudTV RXT
  4. RXT-enabled application or device
04 · Access and visibility

Control access and see how every route performs.

When a reusable playback address is not enough.

Public playback addresses can be copied, replayed, shared, or embedded on an unauthorized site. Delivery teams also need to know which edges are serving viewers, whether sessions are healthy, and how much traffic each live route uses.

Protected routes can apply signed playback requests, fingerprint authorization, expiration and replay checks, session controls, and domain or playback-environment policies before edge selection. Public and protected routes both report session status, bandwidth, delivery health, region, selected edge, and CDN usage.

Best suited to Paid and subscription live services, content providers that need to reduce unauthorized reuse, operations teams that compare delivery quality by route and region, and enterprise live services that need dependable CDN usage records.
Viewer request
Public validationorProtected access checks
Global route selection
Edge deliverySession status · Analytics · Usage

How live delivery works

Connect the source once. Route each viewer independently.

A live source can enter through standard publishing, origin pull, CloudTV RXT, or Live Media Core. Each playback request is checked against the route policy and directed to a healthy edge based on the viewer’s region, edge availability, and current load.

CloudTV PlatformSourceDelivery protocolsRegionsAccessUsage
Source enters once
  • Standard publishing
  • Origin pull
  • RXT-enabled publishing
  • Live Media Core output
Live networkIngest edgeInter-edge live deliveryThe source is not republished separately to every playback edge.
Every viewer request
  1. Public validation or protected access checks
  2. Viewer region · Edge health · Current load
  3. Best available playback edge
Endpoint decides the transport
Standard playbackTCP Boost at the edge
or
RXT-enabled playbackCloudTV RXT
Delivery analyticsSession statusUsage metering

Different viewers can be assigned to different healthy edges as conditions change. If an edge is unavailable or outside the accepted load range, the route can fall back to another available edge. This is live delivery, not video-file hosting: the workflow does not create or maintain a customer media library.

Ingest and delivery

Publish with familiar protocols. Deliver through the formats viewers already use.

Choose how the source enters the network separately from how viewers receive it. Add an accelerated transport path only for endpoints that support it.

Standard publishing

Push an existing live source into the network.

  • RTMP / RTMPS
  • RTSP / RTSPS
  • SRT
  • WebRTC / WHIP
  • MPEG-TS over TCP or UDP
  • RTP where configured
Origin pull

Let the ingest edge retrieve an existing live source.

  • RTMP / RTMPS
  • RTSP / RTSPS
  • SRT
  • WebRTC / WHEP
  • HLS
  • DASH
  • HTTP / HTTPS FLV
  • HTTP / HTTPS MPEG-TS
  • HTTP / HTTPS fMP4
Viewer delivery

Serve the live formats viewers already use.

  • HTTP / HTTPS MPEG-TS
  • HLS
  • HTTP / HTTPS FLV
  • WebSocket / Secure WebSocket FLV
  • HTTP / HTTPS fMP4
  • WebSocket / Secure WebSocket fMP4
  • DASH
  • RTMP / RTMPS
  • RTSP / RTSPS
  • WebRTC / WHEP
Accelerated publishing

Carry a difficult ingest route over CloudTV RXT.

Use a local RXT Proxy, SDK, client, or another enabled endpoint. A local RXT Proxy can receive a standard push from an existing encoder and carry the difficult segment to a CloudTV edge over RXT.

Playback transport

Standard TCP playback TCP Boost at the edge

RXT-enabled playback CloudTV RXT

Compatible protected outputs

Encrypted HLS Requires the corresponding Rights Protection configuration

DASH with DRM Requires the corresponding Rights Protection configuration

Global Edge CDN distributes a configured compatible live output. When the source must be transcoded, repackaged into an incompatible protocol, or converted to another bitrate, enable Live Media Core before CDN delivery. HTTP Boost and P2P Delivery belong to Native SDK & Applications, not the CDN edge.

Access policy

Keep public streams simple. Add stronger controls where needed.

Public routes remain easy to access. Protected routes can bind a signed playback session to expected viewer and device characteristics, apply expiration and session rules, and reject copied or replayed requests before edge delivery.

Viewer requestPublic playback address
Basic request validation
  • Route and request format
  • Basic abuse safeguards
  • Usage and status records
After access checksGlobal edge selectionEdge delivery
Fingerprint authorization

Bind playback to the expected session and environment.

Fingerprint authorization is designed to reduce hotlinking, copied-address reuse, replay, and abnormal use. It is not viewer identity verification or DRM, and no authorization method can eliminate every form of abuse.

Delivery records

Keep access and delivery evidence together.

  • Active sessions
  • Traffic and bandwidth
  • Region and selected edge
  • Request and delivery status
  • Usage metering

These records describe CDN delivery and usage. Viewer plans, subscriptions, payments, and customer charging belong to Business Management.

Live-first edge transport

A live CDN should improve the path after the edge, too.

Placing a live stream near the viewer shortens the route, but it does not remove latency, packet loss, or unstable throughput from the final network path. CloudTV combines live-aware edge selection with TCP Boost for standard players and CloudTV RXT for enabled applications.

General-purpose delivery
  1. Live source
  2. Nearby edge
  3. Standard playback connection
  4. Viewer

Moving the source closer shortens the path. The final viewer connection remains a standard route.

CloudTV live delivery
Live source → Best available healthy edge
TCP BoostExisting browser, player, or application
or
CloudTV RXTRXT-enabled application or device

The endpoint determines the path. TCP Boost and CloudTV RXT do not switch inside one connection.

TCP Boost

Improve compatible standard TCP playback from the edge without changing the viewer’s browser, player, application, or playback protocol.

CloudTV RXT

Use a coordinated transport path between the selected edge and an RXT-enabled application or device when network conditions are more severe.

Recorded playback comparison

Measure the path to the viewer—not just the distance to the edge.

Each comparison uses the same endpoints and payload for the standard and accelerated path. The chart shows every run; the table reports elapsed time as well as throughput.

Recorded evidence
ComparisonStandard TCP playback vs TCP Boost
TopologySame public intercontinental route and remote host
Workload20 MiB HTTP media transfer
Network profile177 ms observed RTT · 34.5% observed loss on the TCP Boost path
Test record28 April 2026 · Build 43296df · 2 runs per path · 120-second limit

Bars show per-run goodputThe table reports median and range

Standard TCP playback vs TCP Boost
RunStandard TCPTCP BoostStatus

Median goodput: 16.16 Mbps with Standard TCP and 28.55 Mbps with TCP Boost. Both paths completed 2/2 runs.

Results describe the recorded routes and workloads, not a guarantee for every network. Actual performance varies by route, workload, bitrate, endpoint, and configuration.

Delivery operations

See each live route as it moves through the network.

Follow viewer distribution, selected edges, session activity, bandwidth, delivery health, and usage from the same control plane used to configure the route.

CloudTV Platform Global Edge CDN overview showing global viewer and edge distribution, edge health, bandwidth, access policy, requests, protocols, and usage by route and region
The preview illustrates the operational information available for CDN routes. Example values describe the interface only; they are not performance evidence, viewer revenue, customer charges, or a CDN bill. Open full-size preview

Fit your existing stack

Keep your origin and players. Change only the delivery path.

Use your own origin and existing players with Global Edge CDN, or add CloudTV processing, transport, applications, protection, subtitles, and business operations only where the live service needs them.

Source optionsYour originStandard publish · Origin pull · Live Media Core · RXT-enabled publishing
DeliveryGlobal Edge CDNPer-viewer edge selection · TCP Boost · Access policy
Playback optionsKeep the player that fitsStandard playback with an existing player · RXT playback with an enabled application
CloudTV PlatformSourcesDelivery protocolsAccessRegionsUsage
Required platform

CloudTV Platform

Sources · Delivery protocols · Access · Regions · Usage

Optional processing

Live Media Core

Protocol conversion · Transcoding · Bitrate profiles · Live Subtitles

Optional transport

Resilient Transport

TCP Boost for compatible standard playback · CloudTV RXT for enabled endpoints

Optional applications

Native SDK & Applications

Not required for standard playback · Required for an RXT-enabled client

Optional protection

Rights Protection

Encrypted HLS · DASH with DRM · Invisible watermarking

Optional operations

Business Management

Content · Plans · Subscriptions · Customers · Devices

Optional subtitles

Live Subtitles

Speech recognition · Multilingual subtitles · Requires Live Media Core

Global Edge CDN can distribute a compatible customer origin directly; Live Media Core is not required. Standard delivery does not require a CloudTV SDK. Fingerprint authorization is a Global Edge CDN access policy and remains separate from DRM and invisible watermarking in Rights Protection. Services are enabled only where the route needs them.

Plan the delivery route

Tell us where your viewers are—and where playback breaks down.

Share your origin location, publishing method, output protocols, audience regions, expected concurrency, and the networks where viewers struggle. We’ll help map the delivery route and the right edge transport options.

Discuss your delivery route