Please see the TVDNS wiki page for notes, examples and discussion relating to the TVDNS specification.
TVDNS is a mechanism for connected receivers to construct a fully-qualified domain name (FQDN) for a particular broadcast service — typically, but not necessarily, a television station.
TVDNS is an extension to RadioDNS, and is defined along
the same lines: the TVDNS specification defines an additional root domain
tvdns.net), and a mapping scheme which formulates a FQDN based
upon specific values from the DVB Service Information (SI).
Once a fully-qualified domain name has been constructed, a connected device
can perform DNS lookups in order to locate IP-delivered applications relating
to that station. These applications are principally advertised by way of
records. Further background can be found on the RadioDNS website.
TVDNS allows a content provider to offer ancilliary services and content without requiring modifications to the broadcast stream. This is especially important for smaller broadcasters for whom the finer detail of delivery is outsourced to a third party, or in situations where inserting additional information into the broadcast stream might otherwise be logistically problematic.
TVDNS is broadly agnostic: although it is specified here for DVB-based broadcasting systems, it would also be generally applicable to other systems, such as ATSC and ISDB.
TVDNS is inherently reliant upon a single party and the resources of that party in order to function: the operator of the domain name used as a root in all TVDNS-generated domain names is ultimately responsible for ensuring that a stable and consistent service is available. For some broadcasters, it might be preferable to instead provide a domain name which is used as a service-discovery target as part of the Service Description Table (SDT) contained within the broadcast stream — this would allow receivers to make the association between a broadcast service and a set of applications advertised through a DNS domain name operated by the broadcaster without involving a third party.
The TVDNS specification is defined as a set of amendments to the RadioDNS Technical Specification (RDNS01 v0.6.1 — 2009-06-15) (PDF).
In this document the domain “
radiodns.org” is used solely to illustrate a unique namespace against which to prepend service parameters to create a resolvable FQDN.
In this document the domains “
radiodns.org” and “
tvdns.net” are used solely to illustrate unique namespaces against which to prepend service parameters to create resolvable FQDNs.
Replace diagram first box caption:
Construct “radiodns.org” URI and query DNS
DNS returns a
Construct “radiodns.org” or “tvdns.net” fully-qualified domain name and perform an
DNS may return
Replace diagram second box caption:
Query DNS using returned
CNAMEwas returned, query DNS within the
CNAMEtarget to locate
Append new section:
The DVB family of broadcasting systems identify services through a combination of several 16-bit unsigned integer identifiers: a
original_network_id, which are assigned by and registered with DVB Services, and a
service_id, both of which are assigned by the registrant of the
network_idvalue. The combination of these three values identifies a particular service, although a given service might be assigned different combinations of identifiers in different broadcasting regions, and may be broadcast by multiple distinct platforms each with their own
network_idregistration and internal identifier assignments.
The FQDN for a DVB service is compiled as follows:
The parameters are populated as follows:
Parameters Description Value Status
Network Identifier The network identifier assigned to the network by DVB Services, or an internally-assigned network identifier taken from the “reusable” network identifier blocks 4-digit hexadecimal mandatory
Service Identifier The service identifier assigned by the platform to a particular station. 4-digit hexadecimal mandatory
Transport Stream (TS) Identifier The transport stream identifier assigned by the platform to a particular station. 4-digit hexadecimal mandatory
Original Network Identifier (ONID) The ONID assigned to the platform by DVB Services 4-digit hexadecimal mandatory
The device should acquire the values for
service_idfrom the DVB/MPEG Transport Stream.
service_idvalues are contained within the Network Information Table (NIT) defined by ETSI EN 300 468 “Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems”.
CNAMErecord unique to each radio service provider must be defned and used to deliver streaming content so that
SRVrecords can be held against this domain instead.
In order to perform application discovery, a client will perform an
ANYDNS query against the FQDN
s1.stream.provider.net.. This FQDN may be a
CNAME(unique to each service) to ease domain management, with
SRVrecords associated with the domain name that is the target of the
CNAME. In this case applications must query for
SRVrecords within the domain that is the target of the
CNAME, rather than the original FQDN.
Remove the following paragraph:
Devices must lookup
SRVrecords on the inital FQDN that the stream is located and not the resultng domain afer
Once the relevant
CNAMErecord has been derived for a service based on the details above, it is antcipated that broadcasters will advertse available applicatons through the use of
SRVrecords associated with that domain record.
Once the relevant fully-qualified domain name has been determined for a service based upon the details above, it is anticipated that broadcasters will advertise services through the use of
SRVrecords associated with that domain. Broadcasters may make use of
DNAMErecords, delegations, or wildcards in order to simplify domain management processes. The implementation of application discovery should first perform an
ANYquery against the fully-qualified domain name for the service, and if this results in a
CNAMErecord being returned, query for application
SRVrecords within the target of that
In the list headed “For IP delivered services:”, replace:
4. Client connects and streams from resolved address
4. Client resolves
stream.musicradio.comto a host address.
5. Client establishes an HTTP connection to the host and begins streaming
/stream.mp3, specifying a
Host:request header of