Hosted & Virtual SAT>IP
What the Category Is, Who Provides It, and How to Choose

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.

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.

Mechanically, the protocol does three things:

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.

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.

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:

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.

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.

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

5.2 Tuner hardware

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

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.

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.

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.

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.

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.

10. About the author