Already have a live stream running on your own server? You do not need to change its source protocol just to distribute it through CDNsun. The useful question is what your origin already makes available: an RTMP stream, an RTSP stream, or an HLS playlist. Each can be pulled into a live delivery workflow, but the processing between your source and your viewers differs.
Pull describes ingest, not playback
A source is the live stream produced by your encoder, camera system, or media server. Pull means we connect to that source on your infrastructure and fetch it. This is different from what viewers receive: the Publishing Point receives the source, while a connected CDN HTTP Live service delivers the stream to viewers through your CDN service domain.
That distinction matters because RTMP and RTSP can be source protocols without becoming viewer playback protocols. With RTMP Pull or RTSP Pull, we convert the incoming stream to HLS for delivery. With HLS Pull, we restream an existing HLS source rather than converting an RTMP or RTSP feed into HLS.
How the three pull methods compare
| Pull method | Existing source format | What CDNsun does | Typical fit |
|---|---|---|---|
| RTMP Pull | Live RTMP stream on your server | Fetches the stream and converts it to HLS for viewer delivery | An encoder or media server already exposes an RTMP URL |
| RTSP Pull | Live RTSP stream on your server | Fetches the stream and converts it to HLS for viewer delivery | An existing camera or media-server workflow exposes an RTSP URL |
| HLS Pull | Existing HLS playlist and segments | Pulls and restreams the HLS stream, including its metadata | Your origin already prepares HLS for playback |
Choose the method that matches your origin
RTMP Pull: keep an established encoder output
RTMP (Real-Time Messaging Protocol) carries live audio and video between streaming systems. It grew out of the Flash era but remains a common output from encoders and media servers.
If your origin already exposes a reachable RTMP stream, RTMP Pull lets us fetch it without making the encoder publish to a new destination. We then convert that feed to HLS for viewer delivery. This is a natural choice when an encoder already sends to your media server: that established path can stay in place while the Publishing Point reads the server’s RTMP URL. The CDN HTTP Live service then distributes the resulting HLS stream without making your media server the viewer-facing endpoint.
RTSP Pull: bring a camera or media-server feed into HLS delivery
RTSP (Real Time Streaming Protocol) is used to establish and control streaming sessions. It remains common in camera and media-server workflows, where an RTSP URL provides access to a live feed.
If your existing origin makes an RTSP stream available, RTSP Pull lets us fetch it from that source. We then convert that feed to HLS for viewer delivery. This fits a camera or media-server installation that already exposes the required live feed through an RTSP URL, so you can retain that source workflow. The Publishing Point connects to the feed, while the CDN HTTP Live service provides an HTTP-based stream for the audience.
HLS Pull: restream HLS you already produce
HLS (HTTP Live Streaming) is an HTTP-based format for live video playback. It uses a playlist, typically an .m3u8 file, that references media segments.
If your origin already publishes HLS, HLS Pull lets us fetch and restream that stream, including its metadata, through CDN HTTP Live. Your origin continues to produce the playlists and segments. This is the natural choice when your media server already packages the live feed as HLS and you want to distribute that output without changing its source format. Keep the playlist and the segments it references available to the Publishing Point as the live stream progresses.
For a continuous 24/7 channel, the same choice applies: use the format your origin already provides, and keep that source available for the Publishing Point to pull. Pull does not itself create a live feed when the origin stops producing one.
Connect the source to viewer delivery
First, create a Publishing Point for your existing source. It tells us where to pull the RTMP, RTSP, or HLS stream from; the setup guide explains the source details. Then create a CDN HTTP Live service using that Publishing Point as its origin. The Publishing Point receives the stream; the service delivers it to viewers through the CDN service domain.
For technical details, see our CDN HTTP Live documentation; our live streaming solution page explains the wider delivery model. We also support RTMP Push and HLS Push for sources that send streams to us; we will cover those workflows in a future article.
Why deliver the stream through CDNsun?
Source ingest and viewer delivery impose very different loads. At sufficient audience scale, a 10–20 Mbps incoming stream could correspond to tens of Gbps of aggregate viewer traffic; the actual outbound volume depends on concurrency and stream bitrate. We distribute that traffic through our CDN, so your origin does not have to carry each viewer connection, its bandwidth, or the associated request processing. Configurable points of presence (PoPs) let you align delivery coverage with your audience.
Our usage reports support live operations: live reports update every minute, while real-time reports are available almost instantly. You can monitor transferred traffic and bandwidth, use HTTP status-code counts as a proxy for request volume, and track cache hit ratio. Detailed raw access logs can be enabled; real-time log forwarding is available on request.
For controlled access to a live stream, CDN HTTP Live supports HLS-specific URL signing. Our pay-as-you-go pricing has no separate charge for streaming or transcoding. Technical support is available 24/7, and custom solutions are available on request.
Have an existing live RTMP, RTSP, or HLS source? Connect it with CDNsun during a free 15-day trial.