This is Project Baird.

Automatic Service Discovery with TVDNS

Preamble

Please see the TVDNS wiki page for notes, examples and discussion relating to the TVDNS specification.

Introduction

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 SRV records. Further background can be found on the RadioDNS website.

Benefits of TVDNS

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.

Downsides to TVDNS

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.

TVDNS Specification (r02 - 2010-06-12)

The TVDNS specification is defined as a set of amendments to the RadioDNS Technical Specification (RDNS01 v0.6.1 — 2009-06-15) (PDF).

Technical Specification → Concept

Replace:

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.

with:

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 CNAME

with:

Construct “radiodns.org” or “tvdns.net” fully-qualified domain name and perform an ANY DNS query

DNS may return CNAME, DNAME, or NS records

Replace diagram second box caption:

Query DNS using returned CNAME to locate SRV records

with:

If a CNAME was returned, query DNS within the CNAME target to locate SRV records

Technical Specification → Implementation → Digital Video Broadcasting (DVB)

Append new section:

The DVB family of broadcasting systems identify services through a combination of several 16-bit unsigned integer identifiers: a network_id and an original_network_id, which are assigned by and registered with DVB Services, and a transport_stream_id and service_id, both of which are assigned by the registrant of the network_id value. 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_id registration and internal identifier assignments.

The FQDN for a DVB service is compiled as follows:

<network_id>.<service_id>.<transport_stream_id>.<original_network_id>.dvb.tvdns.net.

The parameters are populated as follows:

Parameters	Description	Value	Status
network_id	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_id	Service Identifier The service identifier assigned by the platform to a particular station.	4-digit hexadecimal	mandatory
transport_stream_id	Transport Stream (TS) Identifier The transport stream identifier assigned by the platform to a particular station.	4-digit hexadecimal	mandatory
original_network_id	Original Network Identifier (ONID) The ONID assigned to the platform by DVB Services	4-digit hexadecimal	mandatory

The device should acquire the values for original_network_id, network_id, transport_stream_id and service_id from the DVB/MPEG Transport Stream.

The original_network_id, network_id, transport_stream_id and service_id values 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”.

Technical Specification → Implementation → FQDN construction for IP-delivered services

Replace:

A CNAME record unique to each radio service provider must be defned and used to deliver streaming content so that SRV records can be held against this domain instead.

with:

In order to perform application discovery, a client will perform an ANY DNS query against the FQDN s1.stream.provider.net.. This FQDN may be a CNAME (unique to each service) to ease domain management, with SRV records associated with the domain name that is the target of the CNAME. In this case applications must query for SRV records within the domain that is the target of the CNAME, rather than the original FQDN.

Remove the following paragraph:

Devices must lookup SRV records on the inital FQDN that the stream is located and not the resultng domain afer CNAME resoluton.

Technical Specification → Implementation → Application discovery

Replace:

Once the relevant CNAME record has been derived for a service based on the details above, it is antcipated that broadcasters will advertse available applicatons through the use of SRV records associated with that domain record.

with:

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 SRV records associated with that domain. Broadcasters may make use of CNAME or DNAME records, delegations, or wildcards in order to simplify domain management processes. The implementation of application discovery should first perform an ANY query against the fully-qualified domain name for the service, and if this results in a CNAME record being returned, query for application SRV records within the target of that CNAME.

In the list headed “For IP delivered services:”, replace:

4. Client connects and streams from resolved address http://stream.musicradio.com/stream.mp3

with:

4. Client resolves stream.musicradio.com to a host address.

5. Client establishes an HTTP connection to the host and begins streaming /stream.mp3, specifying a Host: request header of fabfm.musicradio.com.

Revision history

• r02 - 2010-06-12 - Mo McRoberts <mo.mcroberts@nexgenta.com>: Clarify DNS resolution and application discovery procedures; formatting fixes.
• r01 - 2010-06-12 - Mo McRoberts <mo.mcroberts@nexgenta.com>: Initial revision.