EN 50585:2014

Communications protocol to transport satellite delivered signals over IP networks

This European Standard describes the SAT>IP communication protocol. It enables a SAT>IP server to forward satellite delivered signals to SAT>IP clients over IP networks. The typical use case would be the transport of television programs that were received from the satellite by the SAT>IP server to the SAT>IP client via the IP network. SAT>IP specifies a control protocol as well as the media transport (Figure 1). SAT>IP is not a device specification. The SAT>IP protocol distinguishes between SAT>IP clients and SAT>IP servers. SAT>IP Clients SAT>IP clients may reside in set-top boxes equipped with an IP interface or may be implemented as software applications running on programmable hardware such as Tablets, PCs, Smartphones, Connected Televisions. SAT>IP Servers SAT>IP servers may take various forms ranging from large MDU headends servicing whole buildings or communities to in-home IP multiswitches to simple IP adapters for a set-top box to, ultimately, IP LNBs. Actual devices may be clients or servers or both depending on their feature set.

Kommmunikationsprotokoll zum Transport von Satellitensignalen über IP-Netze

Protocole de communication pour le transport des signaux transmis par satellite sur les réseaux IP

La présente Norme européenne décrit le protocole de communication SAT>IP qui permet à un serveur SAT>IP de transférer les signaux transmis par satellite aux clients SAT>IP sur les réseaux IP. Le scénario d'utilisation type est le transport de programmes TV par satellite entre un serveur SAT>IP et un client SAT>IP sur un réseau IP. SAT>IP spécifie un protocole de contrôle, ainsi que le transport multimédia (voir Figure 1). SAT>IP n'est pas une spécification de dispositif. Le protocole SAT>IP établit une distinction entre les clients SAT>IP et les serveurs SAT>IP. Clients SAT>IP Les clients SAT>IP peuvent résider dans des boîtiers décodeurs munis d'une interface IP ou peuvent être mis en oeuvre sous forme d'applications logicielles s'exécutant sur des matériels programmables tels que: tablettes, PC, smartphones, téléviseurs connectés. Serveurs SAT>IP Les serveurs SAT>IP peuvent prendre différentes formes: du simple adaptateur IP pour boîtier décodeur aux LNB (Low Noise Block) IP en passant par les dispositifs IP multicommutateurs domestiques et les grandes têtes de réseau MDU (Multi Dwelling Unit) desservant des collectivités ou des bâtiments entiers. Les dispositifs actuels peuvent être des clients et/ou des serveurs, selon leurs fonctionnalités.

Komunikacijski protokol za signale, poslane transportnemu satelitu po IP-omrežjih

Standard EN 50585 opisuje komunikacijski protokol SAT>IP. Strežniku SAT>IP omogoča, da signale, prejete prek satelita, pošlje odjemalcem SAT>IP prek IP-omrežja. Običajni primer uporabe je prenos televizijskih programov, ki jih strežnik SAT>IP prejme prek satelita, do odjemalca SAT>IP prek IP-omrežja. SAT>IP določa nadzorni protokol in prenos medijev. Protokol SAT>IP ne predstavlja specifikacije naprave. Protokol SAT>IP razlikuje med odjemalci SAT>IP in strežniki SAT>IP. Odjemalci SAT>IP Odjemalci SAT>IP lahko delujejo v komunikatorjih, opremljenih z vmesnikom IP, lahko pa so implementirani kot aplikacije programske opreme, ki se izvajajo na programirljivi strojni opremi, kot so tablični računalniki, osebni računalniki, pametni telefoni in povezani televizijski sprejemniki. Strežniki SAT>IP Strežniki SAT>IP so lahko različnih oblik: od velikih glavnih sprejemnih postaj MDU, ki strežejo celotnim stavbam ali skupnostim, do domačih IP-stikal za satelitsko distribucijo in preprostih IP-pretvornikov za komunikatorje ter IP-LNB-jev. Dejanske naprave so lahko glede na njihov nabor funkcij odjemalci, strežniki ali oboje.

General Information

• Status: Published
• Publication Date: 22-May-2014
• Withdrawal Date: 23-Mar-2017
• ICS: 33.170 - Television and radio broadcasting
• Technical Committee: CLC/TC 209 - Cable networks for television signals, sound signals and interactive services
• Drafting Committee: CLC/TC 209 - Cable networks for television signals, sound signals and interactive services
• Current Stage: 9093 - Decision to confirm - Review Enquiry
• Start Date: 03-Apr-2024
• Completion Date: 23-Sep-2025
• Ref Project: SIST EN 50585:2014 - Communications protocol to transport satellite delivered signals over IP networks

Standards Content (Sample)

SLOVENSKI STANDARD
01-oktober-2014
Komunikacijski protokol za signale, poslane transportnemu satelitu po IP-omrežjih
Communications protocol to transport satellite delivered signals over IP networks
Kommmunikationsprotokoll zum Transport von Satellitensignalen über IP-Netze
Protocole de communication pour le transport des signaux transmis par satellite sur les
réseaux IP
Ta slovenski standard je istoveten z: EN 50585:2014
ICS:
33.170 Televizijska in radijska Television and radio
difuzija broadcasting
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 50585
NORME EUROPÉENNE
EUROPÄISCHE NORM
May 2014
ICS 33.170
English Version
Communications protocol to transport satellite delivered signals
over IP networks
Protocole de communication pour le transport des signaux Kommmunikationsprotokoll zum Transport von
transmis par satellite sur les réseaux IP Satellitensignalen über IP-Netze
This European Standard was approved by CENELEC on 2014-03-24. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2014 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 50585:2014 E
Contents Page
Foreword . 5
Introduction . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions and abbreviations . 8
3.1 Terms and definitions . 8
3.2 Abbreviations . 9
4 Basic description of SAT>IP system . 10
4.1 SAT>IP concept . 10
4.2 Network topology . 10
4.3 Client functionality . 11
4.4 Specification compliance . 11
4.5 Usage scenarios . 11
5 Protocol specification . 11
5.1 General . 11
5.2 UPnP addressing . 13
5.2.1 General . 13
5.2.2 DHCP addressing . 13
5.2.3 Auto-IP addressing . 13
5.3 UPnP Discovery . 13
5.3.1 General . 13
5.3.2 Simple service description protocol SSDP . 13
5.3.3 Server Advertisements . 14
5.3.4 DEVICE ID negotiation . 16
5.3.5 Client Search Requests . 22
5.4 UPnP Description . 23
5.4.1 General . 23
5.4.2 XML Device Description . 23
5.5 RTSP Control . 26
5.5.1 General . 26
5.5.2 Real time streaming protocol RTSP . 26
5.5.3 Setting up a new session . 28
5.5.4 Starting the playout of a media stream (PLAY) . 33
5.5.5 Maintaining a session (OPTIONS) . 35
5.5.6 Modifying a media stream . 36
5.5.7 Joining an existing stream . 37
5.5.8 Listing available media streams (DESCRIBE) . 37
5.5.9 Closing the session and stopping the playout (TEARDOWN) . 40
5.5.10 RTSP Methods . 41
5.5.11 Uniform Resource Identifyer (URI) . 44
5.5.12 Query Syntax . 44
5.5.13 Example of RTSP sequence diagram . 48
5.5.14 Internet Group Management Protocol (IGMP) . 49
5.5.15 Status Code Definitions . 51
5.5.16 RTCP Announcements . 57
5.5.17 HTTP based requests . 58

- 3 - EN 50585:2014
5.6 Media Transport . 58
5.6.1 RTP Transport . 58
5.6.2 HTTP Streaming . 59
5.7 Media Formats . 59
6 Dynamic versus Static Server Operation . 59
6.1 Dynamic Operation (default) . 59
6.2 Static Operation . 59
6.3 Mixed Operation . 60
Annex A (informative) Usage scenarios . 61
A.1 IP Adapter / IP Multiswitch . 61
A.2 IP LNB . 61
A.3 Master STB . 61
A.4 Universal Service Gateway . 62
A.5 IP based SMATV / Multi-Dwelling Units . 62
Annex B (informative) Client Implementation Guidelines . 64
B.1 General . 64
B.2 RTSP Clients . 64
B.2.1 Definition . 64
B.2.2 Client Setup and Configuration Settings . 64
B.2.3 Service Discovery . 65
B.2.4 Channel change implementation . 66
B.3 IGMPv3 Clients . 67
B.3.1 Definition . 67
B.3.2 Client Setup and Configuration Settings . 67
Annex C (informative) Example of SAT>IP Message Exchanges . 70
C.1 Example 1: Unicast Session Setup (no front-end selected) plus three additional channel
changes . 70
C.2 Example 2: Multicast Session Setup with front-end selection and destination address/port . 72
Annex D (informative) Support for DVB-T/-T2 (optional) . 74
D.1 General . 74
D.2 Implementation . 74
Annex E (informative) SAT>IP trademark and certification . 76
E.1 Trademark . 76
E.2 Artwork . 76
E.3 Certification . 76
Bibliography . 77
Figures
Figure 1 — Basic principle of the SAT>IP system . 7
Figure 2 — Different types of live media servers . 11
Figure 3 — SAT>IP protocol stack . 12
Figure 4 — Comparison between SAT>IP and DLNA . 12
Figure 5 — NOTIFY message timing . 14
Figure 6 — DEVICE ID allocation timing . 17
Figure 8 — RTSP Control Example . 26
Figure 9 — Client with two RTSP sessions on the same SAT>IP server carried in different concurrent
TCP connections . 27

Figure 10 — Client with two RTSP sessions on the same SAT>IP server carried in one TCP connection at a
given time . 27
Figure 11 — Stream owner setting up a session and defining the transport . 31
Figure 12 — Non-stream owner joining an already existing multicast stream and defining the transport . 31
Figure 13 — Non-stream owner joining an already existing unicast stream and defining the transport . 31
Figure 14 — Server Stream Output State Machine . 35
Figure 15 — RTSP State Machine . 42
Figure 16 — Operation of SAT>IP in the presence of multiple satellite positions . 46
Figure 17 — Server internal source and frontend selection matrix . 46
Figure 18 — Media stream object definition . 47
Figure 19 — Example of a sequence diagram for RTSP operation . 48
Figure 20 — Example of SAT>IP multicast network diagram . 49
Figure 21 — General membership query message timing . 49
Figure 22 — Group specific query timing . 51
Figure 23 — Transport stream IP encapsulation . 59
Figure 24 — Example of SAT>IP system using static server operation . 60
Figure A.1 — IP Multiswitch application . 61
Figure A.2 — SAT>IP conversion inside an IP-LNB . 61
Figure A.3 — Master-Slave application . 62
Figure A.4 — Universial Service Gateway application . 62
Figure A.5 — IP based SMATV application . 63
Figure B.1 — Example of auto-configuration set-up . 66
Figure E.1 . 76

- 5 - EN 50585:2014
Foreword
This document (EN 50585:2014) has been prepared by CLC/TC 209 "Cable networks for television signals,
sound signals and interactive services".
The following dates are fixed:
• latest date by which this document has to be (dop) 2015-03-24
implemented at national level by publication of
an identical national standard or by
endorsement
(dow) 2017-03-24
• latest date by which the national standards
conflicting with this document have to
be withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. [CEN / CENELEC / CEN and CENELEC] shall not be held responsible for identifying any or all such
patent rights.
Introduction
This standard describes a new communication protocol for the distribution of satellite signals onto IP
networks. It effectively “translates” TV signals, received from satellites in the DVB-S and DVB-S2 formats and
st
supplied in the first intermediate frequency range (1 IF range), into signals for use on internet-based devices
in the IP world. This technology enables the reception of satellite TV on devices that do not have an integrated
satellite receiver. Satellite signals can thus be transported via every IP infrastructure with or without cable.
This way, the entire satellite household can be provided with TV and sound radio programmes on tablets,
PCs, laptops, smart phones, connected TVs, game consoles and media players.
1)
This technology concept is commonly referred to as SAT>IP .

1) SAT>IP is a short-term which covers the complete system for the transposition of SAT-IF signals to IP-based signals. This term is used
in a widespread manner for marking software and hardware components used in such systems. More details are given in informative
Annex E.
- 7 - EN 50585:2014
1 Scope
This European Standard describes the SAT>IP communication protocol. It enables a SAT>IP server to
forward satellite delivered signals to SAT>IP clients over IP networks. The typical use case would be the
transport of television programs that were received from the satellite by the SAT>IP server to the SAT>IP
client via the IP network. SAT>IP specifies a control protocol as well as the media transport (Figure 1).
Protocol
IF
Server IP
Client
Live Television
Figure 1 — Basic principle of the SAT>IP system

SAT>IP is not a device specification.
The SAT>IP protocol distinguishes between SAT>IP clients and SAT>IP servers.
SAT>IP Clients
SAT>IP clients may reside in set-top boxes equipped with an IP interface or may be implemented as software
applications running on programmable hardware such as Tablets, PCs, Smartphones, Connected Televisions.
SAT>IP Servers
SAT>IP servers may take various forms ranging from large MDU headends servicing whole buildings or
communities to in-home IP multiswitches to simple IP adapters for a set-top box to, ultimately, IP LNBs.
Actual devices may be clients or servers or both depending on their feature set.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 29341-1-1, Information technology — UPnP Device Architecture — Part 1.1: UPnP Device
Architecture Version 1.1
ETSI TS 101 154 V1.9.1, Digital Video Broadcasting (DVB); Specification for the use of Video and Audio
Coding in Broadcasting Applications based on the MPEG-2 Transport Stream
RFC 2113 – IP Router Alert Option (Internet Engineering Task Force (IETF))
RFC 2131 – DHCP (Dynamic Host Configuration Protocol) (Internet Engineering Task Force (IETF))
RFC 2250 – RTP Payload Format for MPEG1/MPEG2 Video (Internet Engineering Task Force (IETF))
RFC 2279 – UTF-8, a transformation format of ISO 10646 (Internet Engineering Task Force (IETF))
RFC 2326 – Real Time Streaming Protocol (RTSP) (Internet Engineering Task Force (IETF))
RFC 3376 – Internet Group Management Protocol, Version 3 (Internet Engineering Task Force (IETF))
RFC 3550 – RTP: A Transport Protocol for Real-Time Applications (Internet Engineering Task Force (IETF))
RFC 4566 – SDP: Session Description Protocol (Internet Engineering Task Force (IETF))
draft-cai-ssdp-v1-03 – Simple Service Discovery Protocol/1.0 (Internet Engineering Task Force (IETF))

3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
dynamic server operation
server that is dynamically connected to a tuner when a TV program is requested in the IP format by a user
3.1.2
live television
delivered from signal source to end-user equipment without significant delay but with the possibility of
(several) changes of transmission format
3.1.3
multicast data transmission
unique transmission of data signals from one server to more than one client
3.1.4
multiswitch server
server that is connected to a number of tuners in order to deliver channels requested by customers
3.1.5
SAT>IP
short-term which covers the complete system for the transposition of SAT-IF signals to IP-based signals
Note 1 to entry: This term is used in a widespread manner for marking software and hardware components used in
such systems.
3.1.6
SAT>IP client
receive satellite delivered signals from SAT>IP server via IP networks; which may reside in set-top boxes
equipped with an IP interface or may be implemented as software applications running on programmable
hardware such as tablets, PCs, smartphones, connected televisions
3.1.7
SAT>IP server
transforms satellite signals, delivered in the SAT-IF format, to the IP format and transport it to SAT>IP clients
via IP networks; which may take various forms ranging from large MDU headends servicing whole buildings or
communities to in-home IP multiswitches to simple IP adapters for a set-top box to, ultimately, IP LNBs
3.1.8
static server operation
server that is always connected to a number of tuners to provide the wanted TV programs in the IP format
3.1.9
unicast data transmission
data signal transmission from one server to only one client

- 9 - EN 50585:2014
3.2 Abbreviations
CSV Comma Separated Values
DHCP Dynamic Host Configuration Protocol
DiSEqC
Digital Satellite Equipment Control
DLNA Digital Living Network Alliance
DSL Digital Subscriber Line
DVB Digital Video Broadcasting
DVB-S DVB for Satellite
nd
DVB-S2 2 generation DVB for satellite
DVR
Digital Video Recorder
FEC Forward Error Correction
GENA General Event Notification Architecture
HTML HyperText Markup Language
HTTP Hyper Text Transfer Protocol
HSPA High Speed Packet Access
IF
Intermediate Frequency
IGMP Internet Group Management Protocol
IP Internet Protocol
LAN Local Area Network
LNB Low Noise Block
MDU Multi Dwelling Unit
MIME
Multipurpose Internet Mail Extensions
MPEG Moving Picture Experts Group
MPTS Multiple Program Transport Stream
MTU Maximum Transmission Unit
MUDP Multicast UDP
NAS Network Attached Storage
PID
Packet Identifier
PLC Power Line Communication
PoE Power over Ethernet
PSK Phase Shift Keying
PVR Personal Video Recorder
QPSK Quaternary Phase Shift Keying
RFC
Request For Comments
RTP Real-time Transport Protocol
RTCP Real-time Transport Control Protocol
RTSP Real Time Streaming Protocol
SDES Source Description
SDP Session Description Protocol
SI
Service Information
SMATV Satellite Master Antenna Television
SOAP Simple Object Access Protocol
SPTS Single Program Transport Stream
SR Sender Report
SSDP Simple Service Discovery Protocol
STB
Set-Top-Box
TCP Transport Control Protocol
TS Transport Stream
TTL, ttl Time to live
UDP User Datagram Protocol
UPnP Universal Plug and Play
UPnP AV
UPnP Audio and Video
URI Uniform Resource Identifier
URL Uniform Resource Locator
urn universal resource name
UTF UCS Transformation Format
WLAN Wireless Local Area Network
XML
Extensible Markup Language
4 Basic description of SAT>IP system
4.1 SAT>IP concept
Unlike in today’s satellite distribution schemes, the SAT>IP architecture allows the reception of satellite
television programs also on devices which do not have a satellite tuner directly built-in. Satellite tuners and
demodulators are moved or “remoted” into SAT>IP server devices. Clients control SAT>IP servers via the
SAT>IP protocol. SAT>IP is a remote tuner control protocol which provides the possibility of remotely
controlling tuning devices.
This means that the reception of satellite delivered programming can be dealt with by clients purely in
software, provided a SAT>IP server is available on a network. Satellite programs become available on
devices which would never be capable of supporting satellite TV otherwise e.g. Tablets.
From the distribution point of view, satellite distribution becomes physical layer agnostic and satellite services
can be forwarded over all the latest types of wired or wireless technologies such as Powerline (PLC), Wireless
LANs, Optical Fibre Distribution, etc.
4.2 Network topology
The SAT>IP protocol is designed to suit different application scenarios. The same SAT>IP client can
communicate with various types of live media servers ranging from single satellite, single tuner servers to
multi-satellite multi-tuner servers (Figure 2). SAT>IP clients can be designed to work in single home scenarios
as well as in SMATV or large community systems.

- 11 - EN 50585:2014
The number of clients that can be simultaneously supported depends on the particular server implementation.
Large servers can potentially serve an unlimited number of SAT>IP clients. SAT>IP servers can also be
stacked and run in parallel on the same network.

IP Network
SAT>IP Server
Sat 1
multi-tuner
SAT>IP Client
Sat 1
SAT>IP Server
multi-tuner
Sat 2
SAT>IP Client
Sat 1
Sat 2
SAT>IP Server
Sat 3
Sat 4 SMATV
Sat 5
multi-tuner
Sat 6
SAT>IP Client
Figure 2 — Different types of live media servers
4.3 Client functionality
SAT>IP is a client driven architecture. Clients send requests to servers. Servers execute these requests and
forward live television programs to clients.
SAT>IP servers ideally do not need to be configured. They are purely connected to IF satellite signals on their
input and the IP network on their output.
Clients specify what they would like to receive. In this sense SAT>IP is very much comparable to today’s
satellite distribution architectures which are also not aware of the particular signals being received and
watched by clients.
SAT>IP servers are flexible in the way in which signals are transported to clients, however the logic of what is
being received resides in the clients.
SAT>IP does not specify the mechanisms through which SAT>IP clients learn about the streams which are
available to them. Clients can parse DVB Service Information / Program Specific Information for learning
about services available, but they can also rely on service lists containing this information.
4.4 Specification compliance
In order to be compliant with the SAT>IP specification, SAT>IP servers need to fully implement the following
specification. All protocol mechanisms and tools shall be implemented.
SAT>IP clients on the other hand only need to implement the mechanisms which allow them to properly
operate in a UPnP and RTSP environment.
4.5 Usage scenarios
The SAT>IP protocol has been designed with several use cases in mind which are described in informative
Annex A. This listing is however not exhaustive, it is simply meant to describe the most common usage
scenarios.
5 Protocol specification
5.1 General
The SAT>IP protocol allows IP based clients to interact/communicate with IP based satellite servers for live
media forwarding.
Protocol
SAT>IP builds on industry standards and does complement those only where necessary i.e. where there are
no established satellite specific extensions.
The SAT>IP protocol makes use of:
 UPnP for Addressing, Discovery and Description,
 RTSP or HTTP for Control,
 RTP or HTTP for Media Transport.

The SAT>IP protocol stack is organised as shown in Figure 3.
Media Plane Control Plane
Server or Client Application
Media Stream Media Control Device Control
RTP/RTCP HTTP RTSP or HTTP SSDP
(M)UDP TCP TCP (M)UDP
IGMP
IPv4
Figure 3 — SAT>IP protocol stack
SAT>IP uses a subset of the UPnP/DLNA architecture and protocols described in ISO/IEC 29341-1-1 and in
RFC 2113 and SAT>IP devices can be extended to also become DLNA devices (Figure 4). As an example a
SAT>IP client could access live media streams through the SAT>IP protocol and access recorded media
streams through DLNA.
SAT>IP DLNA
Transport Stream (TS) Multiple formats
Media Format
HTTP 1.0/1.1 or RTP
Media Transport
Presentation
HTML
Eventing
GENA
RTSP or HTTP SOAP
Control
Description XML
Discovery SSDP
Addressing
DHCP / Auto-IP
IP
Network Stack
Figure 4 — Comparison between SAT>IP and DLNA
SAT>IP devices successively go through the following phases: Addressing, Discovery, Description, Control
and finally Media Transport.
UPnP
- 13 - EN 50585:2014
5.2 UPnP addressing
5.2.1 General
Addressing is the process for a SAT>IP device (client or server) to obtain a network address. This is a
pre-requisite before any communication can take place. SAT>IP follows the UPnP specification
(ISO/IEC 29341-1-1) by offering the following two options for address acquisition:
5.2.2 DHCP addressing
Every SAT>IP device shall have a Dynamic Host Configuration (DHCP) client and search for a DHCP server
when the device is first connected to the network (RFC 2131). The device from that point onwards shall use
the IP address assigned to it.
5.2.3 Auto-IP addressing
If no DHCP server can be located, the network is unmanaged and SAT>IP devices shall autoconfigure their IP
address according to RFC 3376 from the Auto-IP range 169.254/16. In Auto-IP mode, SAT>IP servers shall
periodically check for the existence of a DHCP server. All SAT>IP protocol mechanisms (SSDP, RTSP,.)
shall work correctly whichever way the IP address is obtained.
5.3 UPnP Discovery
5.3.1 General
During the discovery phase SAT>IP servers advertise their presence to other SAT>IP servers and clients.
When joining a network, SAT>IP clients search the network for available SAT>IP servers.
5.3.2 Simple service description protocol SSDP
Discovery in SAT>IP relies on draft-cai-ssdp-v1-03, Simple Service Description Protocol SSDP as specified in
the UPnP Device Architecture 1.1 (ISO/IEC 29341-1-1).
As a minimum:
 a SAT>IP server is a UPnP Device and a UPnP Control Point,
 a SAT>IP client is a UPnP Control Point.

DEVICE TYPE / URN
Every UPnP device has a specific type corresponding to a certain category of device. This is expressed with a
Unique Resource Name (URN) in UPnP.
The device type of a SAT>IP device shall be:
urn:ses-com:device:SatIPServer:1
where:
 "ses-com" is the domain-name,
 "SatIPServer" is the deviceType name,
 and "1" is the version of the device type.

UUID
Each instance of a SAT>IP server is uniquely identified by its Universally Unique Identifier (UUID) string. The
UUID string shall have the format specified in ISO/IEC 29341-1-1: 4B-2B-2B-2B-6B where B represents a
Byte written as two hexadecimal digits. The UUID of a device shall always remain fixed.
Example of a UUID string:
“2fac1234-31f8-11b4-a222-08002b34c003”

5.3.3 Server Advertisements
SAT>IP servers joining a network multicast three different NOTIFY ssdp:alive messages to the SSDP
address 239.255.255.250 port 1900 (Table 1). This is a requirement for UPnP root devices according to the
UPnP Device Architecture 1.1 (ISO/IEC 29341-1-1).
Table 1 — Multicast NOTIFY ssdp:alive message and example
Method NOTIFY
Request Protocol MUDP (Multicast UDP)
Headers As specified in the UPnP Device Architecture 1.1.
Announcement messages from SAT>IP servers shall include the "DEVICEID.SES.COM:" header extension field
with the DEVICE ID value of a particular server.
Response No response is sent.
Example Request NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=1800
LOCATION: http:///.xml
NT:
NTS: ssdp:alive
SERVER: OS/version UPnP/1.1 product/version
USN:
BOOTID.UPNP.ORG:
CONFIGID.UPNP.ORG:
SEARCHPORT.UPNP.ORG:
DEVICEID.SES.COM:

The NTS header value of these packets is ssdp:alive
The NT (Notification Type) header value is different in each of the three NOTIFY messages. It successively
announces the root device, its device uuid and the urn (see example below).
The USN (Unique Service Name) also changes between the three announcement packets and carries a
composite identifier in concordance with the NT value. Please check Table 1-1 of the UPnP Device
Architecture 1.1 in ISO/IEC 29341-1-1 for more information.
The LOCATION header announces the URL to the UPnP device description (see 5.4). The URL should have
a simple format e.g. http:///desc.xml.
The CACHE-CONTROL header announces the value during which the advertisement remains valid and
before it needs to be re-sent. (1800 seconds in the example above). Multicast NOTIFY ssdp:alive messages
are sent regularly by all SAT>IP servers in order to signal their continued presence. The refreshing of the
NOTIFY advertisement set (consisting of the three messages) has to be done at a randomly-distributed
interval of less than one half of the advertisement expiration date (e.g. 900 seconds for a max-age of 1800
seconds). This guarantees that the announcement set is repeated at least twice before it expires. Figure 5
shows the NOTIFY message timing.

3x NOTIFY max-age=1800 3x NOTIFY max-age=1800 3x NOTIFY max-age=1800
t
pseudo-random pseudo-random
900 s 1800 s
interval interval
server joining
network
Figure 5 — NOTIFY message timing
The BOOTID.UPNP.ORG value shall increase each time that the device first announces on the network. It
shall be stored in non-volatile memory.
The CONFIGID.UPNP.ORG value represents the configuration number of a root device. This value needs to
be identical to the “configId=” value in the section of the XML description file (see 5.4).

- 15 - EN 50585:2014
The SEARCHPORT.UPNP.ORG field is optional. It’s use is not recommended in SAT>IP. SAT>IP devices
are expected to listen to unicast M-SEARCH messages on the standard port 1900. Only if port 1900 is not
available may a device select a different listening port for unicast M-SEARCH messages. If a device sends the
SEARCHPORT.UPNP.ORG header field it shall respond to unicast M-SEARCH messages sent to this
advertised port.
In SAT>IP networks several SAT>IP server devices may coexist on the same network. In order to distinguish
themselves from each other, every device assigns itself a unique DEVICE ID on the network. This DEVICE ID
is carried in the mandatory DEVICEID.SES.COM header field. Its use is explained in 5.3.4.
It should be noted that in UPnP
 header field names are case insensitive and header field values are case sensitive,
 the order of the header fields does not matter,
 linear white spaces following the colon after a header field and in front of a header value shall be
ignored by clients.
The TTL value of each IP multicast packet should default to 2.
Example of the announcement of a SAT>IP server joining the network:
NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=1800
LOCATION: http://192.168.178.21/desc.xml
NT: upnp:rootdevice
NTS: ssdp:alive
SERVER: Linux/1.0 UPnP/1.1 IDL4K/1.0
USN: uuid:50c958a8-e839-4b96-b7ae-8f9d989e136c::upnp:rootdevice
BOOTID.UPNP.ORG: 2318
CONFIGID.UPNP.ORG: 0
DEVICEID.SES.COM: 1
NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=1800
LOCATION: http://192.168.178.21/desc.xml
NT: uuid:50c958a8-e839-4b96-b7ae-8f9d989e136c
NTS: ssdp:alive
SERVER: Linux/1.0 UPnP/1.1 IDL4K/1.0
USN: uuid:50c958a8-e839-4b96-b7ae-8f9d989e136c
BOOTID.UPNP.ORG: 2318
CONFIGID.UPNP.ORG: 0
DEVICEID.SES.COM: 1
NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=1800
LOCATION: http://192.168.178.21/desc.xml
NT: urn:ses-com:device:SatIPServer:1
NTS: ssdp:alive
SERVER: Linux/1.0 UPnP/1.1 IDL4K/1.0
USN: uuid:50c958a8-e839-4b96-b7ae-8f9d989e136c::urn:ses-com:device:SatIPServer:1
BOOTID.UPNP.ORG: 2318
CONFIGID.UPNP.ORG: 0
DEVICEID.SES.COM: 1
A SAT>IP server present on the network has to re-announce itself on a regular basis as described under
CACHE-CONTROL above.
A SAT>IP server leaving the network needs to signal its departure by sending three different NOTIFY
messages with the NTS value ssdp:byebye.
It should be noted that the ssdp:byebye messages should not include the CACHE-CONTROL, LOCATION,
SERVER and DEVICEID.SES.COM headers. An example of such ssdp:byebye messages is shown in 5.3.4.1.

A SAT>IP server changing the network e.g. when passing from an Auto-IP network to a network with a
DHCP assigned address shall signal its departure from one network by sending three NOTIFY messages with
the NTS value ssdp:byebye on that network and shall announce its presence on the new network by sending
three NOTIFY ssdp:alive messages.
SAT>IP clients (being at a minimum only UPnP Control Points) do not announce their presence. For this
reason, a client leaving the network is not detectable at this level. The SAT>IP protocol however implements
RTSP and IGMP which permit to detect the presence or absence of a client (RTSP session timeout, IGMP
membership queries).
5.3.4 DEVICE ID negotiation
5.3.4.1 General description
Every SAT>IP server on a network carries its own non-clashing DEVICE ID value. The DEVICE ID value is
negotiated between different SAT>IP servers when they join the network. The DEVICE ID value allows each
SAT>IP server to uniquely associate itself with a different IP multicast address range on the network (see
below).
When a server performs a cold start it reads the initial DEVICE ID value from its non-volatile memory. This
value shall be the last value that the server had used. The server then multicasts this DEVICE ID value as part
of the announcement NOTIFY messages that were described in 5.3.3.
Other SAT>IP servers already on the network (acting as control points) listen for these announcements.
As long as the DEVICE ID value received by these servers does not conflict with their own DEVICE ID value,
they will not react.
In case of a DEVICE ID conflict, however the server that notices that another server would like to use its own
DEVICE ID (DEVICE ID clash) needs to defend its own DEVICE ID, by sending (within 1 second) a unicast
M-SEARCH message according to Table 2 containing the in-use DEVICE ID to the IP address of the joining
server and port 1900 or the port contained in the SEARCHPORT.UPNP.ORG field if present.
The joining server acknowledges receipt via a 200 OK response repeating the current DEVICE ID value.
Table 2 — Unicast M-SEARCH message and example
Method M-SEARCH
Request Protocol UDP unicast
Headers As specified in the UPnP Device Architecture 1.1.
A request from a server shall include a "DEVICEID.SES.COM:" field name with the DEVICE ID value of that server.
The target server acknowledges receipt in repeating the DEVICE ID value in the response.
A "DEVICEID.SES.COM:" field shall not be included in a client request.
Response Line HTTP/1.1 200 OK
Protocol UDP
Headers As specified in the UPnP Device Architecture 1.1.
The "DEVICEID.SES.COM:" field name with a DE
...