Documentation
Hosted & Virtual SAT>IP
A reference for hosted and virtual SAT>IP: how the protocol works, the four delivery models, shared vs private tuners, and the providers in the market. It also covers how to choose and when hosted reception isn’t the right fit.
- 2026-10-09 11:50
- 2026-10-13 12:44
- Definitions
- Four delivery models
- Software & hardware landscape
- Selection criteria
- Standards
In One Line
What the category is
Someone else operates the dish and the tuner; you receive the transport stream over IP.
Signal — satellite, at a site with a dish
↳ Tuner — demodulates to a transport stream
↳ IP — the stream reaches you
↳ Your software — treats it as a local tuner
- Protocol1.2.2SAT>IP, current
- Published2012SES-led consortium
1. Why this reference exists, and how to read it
Satellite reception delivered over IP is a real category with real providers, but it has no agreed vocabulary. The same offering is marketed as a “virtual tuner”, a “hosted tuner”, “satellite as a service”, “remote DVB”, “headend as a service” and “cloud SAT>IP”, and those phrases are used inconsistently even within a single vendor’s own material. Buyers cannot compare what they cannot name.
This page is written to be quotable by people who are not us: journalists, analysts, forum contributors, and engineers writing internal documentation. It therefore names the options we do not sell, describes the self-build route honestly, and states where our own delivery model is the wrong answer.
Disclosure, because it affects how you should read this. SATLINE is a provider in this category — one of several named in section 5. We have tried to write a reference that a competitor could cite without objecting to it, which means describing the buy-and-self-host route as the legitimate engineering choice it often is, and being explicit in section 7 about the cases where a managed tuner is the wrong tool. Where a claim is ours rather than the industry’s, it is marked. Where a figure comes from a specification, the specification is named so you can check it.
Terminology note: this page uses SAT>IP for the specific published protocol, and satellite-over-IP for the broader practice, which also includes multicast, SRT and other transports that are not SAT>IP. The two are routinely conflated, and the distinction matters when you are comparing products.
2. What SAT>IP actually is
SAT>IP is a protocol for making a satellite tuner available over an IP network, so that client software can request a transponder and receive the resulting transport stream as if the tuner were local. It was published in 2012 by a consortium led by SES, the satellite operator, and the current published revision is version 1.2.2.
A correction worth making, because it circulates. SAT>IP is frequently described as being standardised in ETSI TS 103 205. It is not. TS 103 205 is a DVB specification covering CI Plus extensions, an unrelated subject. SAT>IP is a consortium specification published by the SAT>IP project rather than an ETSI deliverable. It is a genuine, openly published protocol — it is simply not that document number, and citing it as such is an error we have seen repeated in otherwise careful material.
Mechanically, the protocol does three things:
| Function | How it works |
|---|---|
| Addressing | The client is pointed at an explicit endpoint — a host and port, and a description document that advertises the tuner’s capabilities. For hosted reception this is always configured deliberately rather than discovered, since a provider’s tuner is not on your network |
| Tuning | An RTSP session, or an HTTP request, carries the tuning parameters as query values — position, frequency, polarisation, symbol rate, modulation, code rate, and which PIDs to deliver |
| Delivery | The transport stream is returned over RTP/UDP or TCP, as a standard MPEG transport stream that any DVB software can consume |
The consequence that defines the category: the tuner does not have to be in the same building as the software. Once tuning is a network request and the result is a transport stream, the physical distance between dish and application is an engineering detail rather than a constraint. That is what makes hosted reception possible at all.
What SAT>IP does not do is change the stream. What arrives is an ordinary MPEG transport stream, with its PSI/SI signalling intact, subject to the same structures and the same failure modes as any broadcast feed — which is why the rest of this documentation set applies unchanged. See MPEG Transport Stream Explained for the container and PSI/SI Tables & Descriptors for the signalling.
3. The four delivery models
Almost every offering in this space is one of four models. Distinguishing them is the single most useful thing a buyer can do, because they differ in cost structure, control, and what breaks.
| Model | Who owns the dish and tuner | What you operate | Typical cost shape |
|---|---|---|---|
| 1. On-premise self-build | You | Everything: dish, LNB, tuner cards, server, software | Capital purchase, then power and rack |
| 2. Colocated hardware | You own it; a facility hosts it | Your hardware and software, someone else’s dish infrastructure and rack | Capital purchase plus monthly colocation |
| 3. Dedicated hosted server | Provider | The software stack on a machine rented whole, with tuner cards and a downlink | Monthly per server |
| 4. Virtual or hosted tuner | Provider | Only your own client software; you rent tuner capacity, not a machine | Monthly per tuner or per frequency |
3.1 What actually separates models 3 and 4
This is where most confusion in the category lives, because both are marketed with similar language. The distinction is whether you rent a machine or tuner capacity.
Dedicated hosted server
A whole server with DVB cards and a satellite downlink. You control the operating system and the full software stack, and you can co-locate other workloads on it — a CAM in a CI slot, a GPU for transcoding, a large DVR array.
Virtual or hosted tuner
Tuner capacity as an endpoint. There is no machine to administer; you point your own software at a SAT>IP URL. Cheaper and faster to start, but you cannot install anything on the provider’s side.
The practical test: if you need something else physically next to the tuner — a conditional-access module in a slot, a GPU, disks — you need a dedicated server or your own hardware. If you only need the stream, a virtual tuner is the cheaper answer and there is nothing to maintain.
3.2 Shared versus private tuners
Within the virtual-tuner model, providers distinguish two sub-types, and the difference decides whether the product fits your workflow at all:
| Shared (frequency-locked) | Private (position-locked) | |
|---|---|---|
| Locked to | One satellite position and one frequency at a time | A satellite position; any transponder on it |
| State | Held permanently tuned, so there is no acquisition delay at session start | Cold until you tune it |
| Can scan the position | No — only the currently locked transponder’s services are visible | Yes, which is what makes transponder discovery and full-position EPG collection possible |
| Shared with others | Yes; the same transponder serves multiple customers | No |
| Best for | Known, stable channel requirements and continuous ingest | Scanning, monitoring across a position, EPG harvesting, changing requirements |
Why the “hot” distinction is a real engineering property, not marketing. A tuner that is already locked to a carrier has no acquisition or FEC-lock delay to pay when a session opens, reconnects, or fails over to a standby path. A cold tuner must acquire the carrier before a single packet moves. For continuous ingest where reconnect time is the thing that shows up as an outage, that difference is the point of the shared model — and it is also why a shared tuner cannot roam: it is holding a lock on your behalf.
4. The three layers, and who supplies each
Any deployment in this category resolves into three layers. Vendors compete in different layers, which is why “who is the competitor” often has no single answer.
| Layer | What it is | Supplied by |
|---|---|---|
| Signal | The satellite feed itself — the capacity, the position, the footprint | Satellite operators (SES, Eutelsat and others). Nobody in this category substitutes for them |
| Hardware | Dish, LNB, and the demodulator: PCIe DVB cards or networked tuners | Tuner manufacturers, or a hosting provider that owns them on your behalf |
| Software | What turns a transport stream into services, recordings or an IP output | Open-source and commercial headend software; usually your choice, not the provider’s |
The category exists because the middle layer can be rented. The signal layer cannot be substituted, and the software layer is normally yours regardless of who supplies the tuner — which is why a good provider is software-agnostic rather than bundling a stack you must adopt.
The geographic constraint that no amount of hardware solves. A satellite beam covers a footprint. If your site is outside it, or the orbital position sits below your horizon, no dish, card or server at your location will receive it — that is geometry, not equipment. This is the one genuinely structural argument for hosted reception: a provider with antennas inside the footprint can deliver a position you physically cannot receive. Conversely, if the position you need is comfortably visible from your own roof and you have the skills, self-build is a perfectly rational choice.
5. The landscape, including what we do not sell
A reference that only named its author’s products would be useless. These are the real options, grouped by what they are. Inclusion is descriptive, not an endorsement, and this is not exhaustive.
5.1 Headend and client software
| Software | What it is | Licence |
|---|---|---|
| TVHeadend | The most widely used open-source DVB recorder and streaming backend. Acts as a SAT>IP client, and is the default answer to “self-host DVB or IPTV” | Open source |
| Cesbo Astra | A commercial Linux software headend that converts DVB to IP, common in operator deployments | Commercial |
| Flussonic Media Server | A commercial streaming server with satellite ingest capability | Commercial |
| VLC, Kodi | General-purpose players that consume SAT>IP sources directly, useful for verification and small deployments | Open source |
| SAT>IP Servers Pro | Server-side software implementing the SAT>IP protocol, including T2-MI de-encapsulation and multistream handling. Published by SATLINE — noted here for completeness, and disclosed as ours | Commercial |
5.2 Tuner hardware
| Hardware | What it is |
|---|---|
| Digital Devices | German-made networked tuners (the Octopus NET family) and PCIe cards. The canonical “buy the hardware and self-install” route, and widely used inside hosting providers’ own machines |
| TBS Technologies | PCIe DVB-S2X cards and IPTV streamers, common in dense multi-tuner builds |
| HDHomeRun | Networked tuners, primarily terrestrial and cable, popular in home deployments |
Worth stating plainly: buying Digital Devices or TBS hardware and running TVHeadend or Cesbo on your own server is a completely legitimate architecture. It is the right answer when you have visibility of the position, in-house Linux capability, and a preference for capital over operating expenditure. The hosted models in section 3 are not better; they trade capital and control for speed, geography and someone else’s operational burden.
5.3 Hosted and managed providers
| Provider | Model |
|---|---|
| SATLINE | Virtual and dedicated satellite tuners plus colocation. Run as a Hostline, UAB project since 2019 and incorporated as Satline, UAB (Vilnius, Lithuania) in 2026, under the same technical lead throughout. The author of this page |
| XSServer | German provider with Netherlands data centre, offering dedicated servers with tuners and preinstalled headend software |
| Skyhosting | Netherlands and Ukraine, tuner tiers on hosted hardware |
| Cloud TVHeadend services | Managed TVHeadend platforms that bundle the software with hosted reception |
| General hosting providers | Several add a satellite feed to otherwise standard dedicated hosting, usually quote-driven and position-limited |
This is a small market. Its most notable feature is that it is under-documented rather than crowded — provider comparison is difficult because published specifications, positions and pricing vary in completeness. That is the gap this page tries to reduce, and the checklist in section 6 is written so it can be applied to any provider here, including us.
6. How to choose: the questions that actually decide it
Applicable to any provider in section 5.3. If a provider cannot answer these from published material, that is itself informative.
| # | Question | Why it decides the outcome |
|---|---|---|
| 1 | Which orbital positions are actually available, and from which receiving sites? | The only question that can rule a provider out outright. A position they cannot see is a position you cannot get |
| 2 | Shared or private tuner — and can you change the frequency yourself? | Decides whether the product supports scanning and full-position EPG, or continuous ingest of a known transponder (3.2) |
| 3 | Full multiplex or selected PIDs, and who decides? | Determines the bandwidth you must provision. A full MPTS can be tens of megabits per second |
| 4 | Is multistream (MIS) and T2-MI handled? | Many European transponders carry multistream carriers or T2-MI-encapsulated DVB-T2 multiplexes. If the provider cannot de-encapsulate, those feeds are unusable to you |
| 5 | What transport is offered — SAT>IP over RTSP, HTTP, multicast, SRT? | Decides whether it survives the public internet. SAT>IP over UDP is designed for a LAN; long-haul usually wants SRT or a managed path |
| 6 | How is conditional access handled, if you need it? | Descrambling requires a legitimate subscription and a module or card server. Establish where that sits and whose agreement covers it |
| 7 | Is reception redundant, and how? | A single antenna at a single site is a single point of failure. Ask specifically what happens during a rain fade or a site outage |
| 8 | Which client software is supported? | A provider presenting a standard SAT>IP source works with anything. A proprietary client is lock-in |
| 9 | What are the commercial terms — monthly, commitment, setup? | The comparison against buying hardware is only meaningful once the term is known |
Question 4 is the one most often skipped and most often fatal. A carrier that looks ordinary in a satellite directory may be a multistream carrier requiring a stream identifier and physical-layer scrambling parameters, or may carry a DVB-T2 multiplex wrapped in T2-MI that must be de-encapsulated before any service is visible. Both are common on European positions. If reception of that specific carrier has not been demonstrated, treat it as unproven rather than assumed. The MPEG-TS sheet covers T2-MI structure and the TSDuck cookbook shows how to verify a live feed yourself.
7. When hosted reception is the wrong answer
A reference with no negative cases is advertising. These are the situations where the models in section 3 do not fit, stated as plainly as we can.
| Situation | Why hosted is the wrong tool |
|---|---|
| You need a physical CI/CAM module in a tuner’s slot | Legacy modules that must occupy a slot adjacent to the tuner require the tuner in your own chassis. Own hardware or a dedicated server, not a virtual tuner |
| You need a GPU or large storage array beside the tuner | Transcoding hardware and DVR capacity live on machines you control. Rent a dedicated server or build it |
| The position is easily visible and you have Linux capability in-house | Self-build is cheaper over a multi-year horizon and gives full control. Hosted reception is buying convenience and geography you do not need |
| You need continuous full-position scanning across many transponders | A frequency-locked shared tuner cannot do it. Either a private position-locked tuner, or your own multi-tuner hardware |
| Your requirement is a handful of free-to-air channels at one home | A consumer networked tuner and a small dish is the proportionate answer. This category is aimed at operators and businesses |
| You need capacity, not reception | If you want to broadcast, you are buying satellite capacity from an operator. That is a different purchase entirely |
8. Standards and specifications that apply
Hosted reception introduces no new broadcast standards. What arrives is a conventional transport stream, so the whole existing body of DVB and MPEG specification applies unchanged — which is the reassuring part of the category and the reason existing tooling works against it.
| Specification | Covers |
|---|---|
| SAT>IP protocol, v1.2.2 | Discovery, tuning and delivery of a satellite tuner over IP. A consortium specification led by SES — not an ETSI deliverable, and not TS 103 205 |
| ISO/IEC 13818-1 / ITU-T H.222.0 | MPEG-2 Systems: the transport stream itself, packets, PIDs, PCR, PSI |
| ETSI EN 300 421 / EN 302 307-1 / EN 302 307-2 | DVB-S, DVB-S2 and DVB-S2X: the satellite physical layer and its MODCODs |
| ETSI EN 300 468 | DVB Service Information — the SI tables that make a stream navigable |
| ETSI TS 102 773 | T2-MI, the encapsulation used to carry DVB-T2 over satellite |
| ETSI TR 101 290 | Measurement guidelines — the standard vocabulary for monitoring stream health |
| ETSI TS 103 197 | DVB SimulCrypt head-end interfaces, where conditional access is involved |
Each of these is treated in depth elsewhere in this documentation set, with the figures read from the published specifications rather than paraphrased: the DVB Standards & C/N Reference for the physical layer, PSI/SI Tables & Descriptors for signalling, Conditional Access & SimulCrypt for CA, and the glossary for terminology.
9. Citing and reusing this page
This reference is intended to be quoted. If it is useful to you, use it — attribution is welcome but the definitions in sections 2 and 3 are offered as vocabulary for the category rather than as proprietary framing.
If you find an error, we would rather know. The correction in section 2 about TS 103 205 exists because the mistake is widespread, including in material written by people who know this field well. If something here is wrong, out of date, or unfair to a named product, tell us and we will correct it and say that we did. A reference that cannot be corrected is not a reference.
Two things this page deliberately does not contain: prices, which change and would date it; and receiving-site locations, which change as infrastructure grows. For current commercial terms see the product pages.
Gleb Sazanov
Chief Technology Officer
Gleb Sazanov is an accomplished Chief Technology Officer (CTO) with over 20 years of experience in software development, system architecture, and cloud-based solutions. As the CTO of SATLINE, a leading provider of virtual and colocation services tailored to SATCOM businesses, Gleb drives the company’s technological strategy, fostering innovation and efficiency in data center services. His expertise spans various domains, including DevOps, system scaling, and high-performance infrastructure management. With a deep passion for cutting-edge technologies, Gleb plays a pivotal role in shaping the future of the SATCOM industry.