Resilient Transport
Keep live streams moving across difficult networks.
Improve live publishing, playback, and transfer when long-distance routes introduce high latency and packet loss. TCP Boost improves compatible standard playback paths without client or player changes, while CloudTV RXT provides a bidirectional accelerated path for enabled endpoints.
- Standard playback
- TCP Boost at the CloudTV edge
- Enabled endpoints
- Bidirectional CloudTV RXT
Route viewLive publishing
Difficult path active
CloudTV RXTLong distance · high latency · packet loss
CloudTV RXT
Standard server-side route
RXT carries the difficult contribution path to a nearby edge. The stream then continues to the selected platform over the configured server-side route.
Configured through CloudTV PlatformOne transport product or part of a wider service.
Configure endpoints, routes and policies, then monitor route health and usage in one place. This remains the same whether Resilient Transport is the only product you use or part of a wider CloudTV service.
- Endpoints
- Routes
- Policies
- Health
- Usage
Where routes break down
Start with the network problem you already see.
Resilient Transport strengthens the difficult segment without requiring you to replace the platform, CDN, meeting service, or playback system on either side.
01 · Cross-border publishing
Publish reliably from wherever you are.
When the ingest server is a long way from the broadcast.
Creators, teachers, remote teams and production crews are often far from the ingest server used by a streaming platform or meeting service. Once the route crosses countries, continents or several carriers, latency and packet loss can reduce upload capacity below the live bitrate, causing dropped frames, stalls or a failed broadcast.
An RXT-enabled endpoint carries the difficult contribution path to a nearby CloudTV edge. From there, the live stream continues to TikTok, YouTube, a meeting service or another destination over the configured server-side route.
Best suited to Cross-border creators, remote lectures and meetings, international events, remote production, and live contribution from temporary or mobile locations.Current route
- Remote encoder
- Long-distance public network
- Platform server
- Viewers
With CloudTV RXT
- RXT-enabled endpoint
- Nearby CloudTV edge
- Platform or meeting service
- Viewers
02 · Stable CDN contribution
Get a stable stream into the CDN before distribution begins.
A CDN cannot repair a stream it never received cleanly.
A CDN can only distribute the live stream that reaches its ingest point. When an origin pushes over a long-distance standard route, or exposes a public address for CDN pull, latency, packet loss or poor single-flow throughput can destabilize the feed before global delivery even begins.
RXT first carries the contribution from the origin to a nearby CloudTV edge. The edge can then push the stream to your CDN, or expose a standard address that your CDN pulls from, so the existing delivery network can remain in place.
Best suited to Broadcasters, live platforms, regional origins, remote production teams, and operators that want to keep their existing CDN while improving the contribution path.Current route
- Your origin
- Long-distance push or pull
- CDN ingest
- CDN edges
With CloudTV RXT
- RXT-enabled origin
- Nearby CloudTV edge
- Push to or pull from your CDN
- Viewers
03 · Difficult viewer networks
Improve playback where a CDN alone is not enough.
The nearest CDN edge is not always the end of the problem.
A CDN shortens the server path, but viewers still depend on their local carrier and access network. Packet loss, congestion and latency on that final route can cause stalls even when the origin and CDN are healthy.
For existing browsers, players and applications, send compatible TCP playback through a CloudTV edge with TCP Boost. When you control the client, an RXT-enabled application can use CloudTV RXT for more severe network conditions.
Best suited to Global live platforms, online education and meeting services, broadcasters, OTT operators, international events, and services whose viewers still experience unstable playback behind an existing CDN.Your origin or existing CDNCloudTV edge
Different endpoint, different path
Two transport paths, built for different endpoints.
TCP Boost improves compatible standard TCP playback connections from the CloudTV edge without changing the player or application. CloudTV RXT links enabled software directly to the edge, allowing both sides to manage transport across more severe network conditions.
TCP Boost
TCP Boost works from the CloudTV edge on compatible TCP playback. It observes changing path conditions and dynamically compensates for packet loss while the browser, player or application continues using its existing playback protocol.
- Server sideCloudTV edge with TCP Boost
- Compatible routeStandard TCP playback
- ViewerExisting browser, player or application
- No player or App changes
- No RXT integration
- Playback direction only
CloudTV RXT
CloudTV RXT coordinates sending, acknowledgement and loss recovery between the enabled endpoint and the CloudTV edge. This gives both sides greater control over the transport path when latency and packet loss make standard connections unable to sustain the required bitrate.
- EndpointRXT-enabled software
- Bidirectional routeCloudTV RXT session
- Server sideCloudTV edge
- Publishing, playback or transfer
- SDK, client, Proxy or compatible endpoint
- Standard protocols can continue beyond the edge
One live service
Serve standard and RXT-enabled endpoints from the same live service.
A standard player keeps its existing playback protocol on a compatible TCP Boost path from the edge. An RXT-enabled application can use RXT instead. The endpoint determines which path is used; the two transports do not switch inside the same connection.
Standard publishing remains unchanged. When the contribution path itself needs acceleration, publish through an RXT-enabled endpoint or a local CloudTV RXT Proxy.
Standard playerTCP Boost playback
RXT-enabled endpointCloudTV RXT
Recorded comparison
Measured on the same route, under the same conditions.
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.
ComparisonStandard TCP playback vs TCP Boost
TopologySame public route and remote host
Network profile177 ms observed RTT · 34.5% observed loss on the TCP Boost path
Workload20 MiB HTTP media transfer
Test record28 April 2026 · Build 43296df · 2 runs per path · 120-second limit
Goodput35 Mbps
Standard TCPTCP Boost
| Run | Standard TCP | TCP Boost | Status |
|---|
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.
Fit the route you already operate
Strengthen the difficult part of the route.
Keep the rest of your stack.
Use RXT between an enabled endpoint and the nearest CloudTV edge, or deliver compatible playback through TCP Boost at the edge. Everything outside the accelerated path can continue using standard protocols and the systems you already operate.
CloudTV PlatformRoutesEndpointsPoliciesHealthUsage
Use RXT without changing your encoder or source system.
CloudTV RXT Proxy runs beside the source and accepts familiar push or pull workflows. Existing streaming software continues using its standard protocol locally, while the proxy carries the difficult network segment over RXT.
Push directly into the local RXT Proxy.
Your encoder continues using its existing push protocol. The proxy receives the stream, transports it over RXT, and forwards it to the nearest CloudTV edge.
- Encoder or source
- Standard push
- Local RXT Proxy
- CloudTV RXT
- Nearby edge
- Destination
- What changes
- CloudTV RXT Proxy is installed near the encoder or source.
- What stays
- The encoder, its standard push protocol, and the destination workflow.
Make a local source available through an RXT-accelerated pull route.
Configure the local RXT Proxy as a reverse proxy for the source, then register its route as the pull source in CloudTV Platform. The source continues serving its existing protocol while the long-distance path is carried over RXT.
- Local source
- Standard pull
- Local RXT Proxy
- CloudTV RXT
- CloudTV edge
- Configured workflow
- What changes
- The local proxy route is registered as the source in CloudTV Platform.
- What stays
- The original source address, source software, and downstream workflow.
Build RXT directly into software you control.
When you control the sender, receiver or application, enable RXT through a CloudTV SDK or compatible endpoint instead of placing a local proxy beside it. The difficult segment runs directly to a nearby CloudTV edge; your platform, CDN and destination workflow can remain unchanged beyond the edge.
- RXT-enabled client, SDK or endpoint
- CloudTV RXT
- Nearby CloudTV edge
- Existing platform, CDN or destination
- What changes
- The controlled endpoint integrates or enables CloudTV RXT.
- What stays
- The destination platform and the workflow beyond the CloudTV edge.
Improve standard playback without rebuilding the client.
Send compatible TCP playback through a TCP Boost-enabled CloudTV edge. The viewer keeps the same browser, player or application and continues using the same playback protocol.
- Your origin or existing CDN
- CloudTV edge with TCP Boost
- Existing browser, player or application
- What changes
- The playback route passes through a TCP Boost-enabled CloudTV edge.
- What stays
- The viewer continues using the existing player and playback protocol.
Use RXT when you control the playback endpoint.
An RXT-enabled application connects directly to the CloudTV edge over RXT, while your origin, media workflow and upstream CDN can stay in place.
- Your origin or existing CDN
- CloudTV edge
- CloudTV RXT
- RXT-enabled application
- What changes
- The application uses an RXT-enabled playback endpoint.
- What stays
- Your origin, media workflow and existing upstream CDN can remain in place.
Carry the difficult part of a system-to-system route.
Use RXT between a compatible remote endpoint and a CloudTV edge when a long-distance, bidirectional transfer cannot sustain the required bitrate. Standard protocols can continue on either side of the accelerated segment.
- Remote system or compatible endpoint
- CloudTV RXT
- CloudTV edge
- Existing origin, CDN or destination
- What changes
- RXT carries the difficult long-distance segment.
- What stays
- Standard protocols can continue before and after the accelerated path.
Start with one network problem
Use Resilient Transport on its own.
Add more only when the workflow needs it.
Every route is configured and monitored from CloudTV Platform. Resilient Transport can solve a publishing, playback, or transfer problem by itself, then connect to additional products when processing, delivery, applications, protection, or business operations are required.
CloudTV PlatformConfiguration · routing · monitoring · usage
Your endpointResilient TransportYour platform, CDN, meeting service or destination
For example, a creator can use RXT to publish to TikTok or YouTube without enabling media processing or CDN delivery.
ProcessLive Media CoreRelay · transcode · protocol conversion
ProcessLive SubtitlesSpeech recognition · multilingual subtitle tracks
ProtectRights ProtectionAuthorization · DRM · invisible watermarking
DeliverGlobal Edge CDNGlobal live-stream delivery
BuildNative SDK & ApplicationsRXT-enabled apps · generated apps · custom development
OperateBusiness ManagementContent · plans · subscriptions · customers · devices · resellers
Dashed connections are optional combinations, not a fixed execution order.
Diagnose the route
Tell us where the route breaks down.
Share the source and destination, protocols, regions, bitrate, and the network symptoms you are seeing. We can help determine whether TCP Boost, CloudTV RXT, or a local RXT Proxy is the right fit.