ETSI TS 103 270 V1.3.1 (2019-05)

RadioDNS Hybrid Radio; Hybrid lookup for radio services

RTS/JTC-052

General Information

• Status: Published
• Publication Date: 15-May-2019
• Technical Committee: BROADCAS - EBU/CENELEC/ETSI on Broadcasting
• Current Stage: 12 - Completion
• Due Date: 20-May-2019
• Completion Date: 16-May-2019

Standards Content (Sample)

TECHNICAL SPECIFICATION
RadioDNS Hybrid Radio;
Hybrid lookup for radio services

2 ETSI TS 103 270 V1.3.1 (2019-05)

Reference
RTS/JTC-052
Keywords
broadcasting, DNS, IP, radio
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
© European Broadcasting Union 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 270 V1.3.1 (2019-05)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 8
4 Introduction . 8
5 Authoritative FQDN resolution, and ServiceIdentifier and bearerURI construction for broadcast
services . 9
5.1 RadioDNS FQDN, ServiceIdentifier and bearerURI construction . 9
5.1.1 FM with RDS/RBDS . 9
5.1.1.1 RDS/RBDS parameters . 9
5.1.1.2 Construction of RadioDNS FQDN . 10
5.1.1.3 Construction of ServiceIdentifier . 10
5.1.1.4 Construction of bearerURI . 10
5.1.2 Digital Audio Broadcasting (DAB/DAB+). 11
5.1.2.1 DAB/DAB+ parameters . 11
5.1.2.2 Construction of RadioDNS FQDN . 11
5.1.2.3 Construction of ServiceIdentifier . 11
5.1.2.4 Construction of bearerURI . 12
5.1.3 Digital Radio Mondiale (DRM) . 12
5.1.3.1 DRM parameters . 12
5.1.3.2 Construction of RadioDNS FQDN . 12
5.1.3.3 Construction of ServiceIdentifier . 13
5.1.3.4 Construction of bearerURI . 13
5.1.4 AM Signalling System (AMSS) . 13
5.1.4.1 AMSS parameters . 13
5.1.4.2 Construction of RadioDNS FQDN . 13
5.1.4.3 Construction of ServiceIdentifier . 13
5.1.4.4 Construction of bearerURI . 13
5.1.5 IBOC . 14
5.1.5.1 IBOC parameters . 14
5.1.5.2 Construction of RadioDNS FQDN . 14
5.1.5.3 Construction of ServiceIdentifier . 14
5.1.5.4 Construction of bearerURI . 14
5.2 Resolution of Authoritative FQDN . 15
6 Authoritative FQDN and ServiceIdentifier resolution and bearerURI construction for IP-streamed
services . 15
6.1 General . 15
6.2 Inclusion of parameters into stream metadata . 16
6.2.1 Streaming transports . 16
6.2.1.1 SHOUTcast . 16
6.2.1.2 ASF . 16
6.2.1.3 Flash Audio . 16
6.2.2 Metadata intervals . 16
6.3 Construction of bearerURI . 17
6.4 Construction of ServiceIdentifier . 17
ETSI
4 ETSI TS 103 270 V1.3.1 (2019-05)
7 Authoritative FQDN and ServiceIdentifier resolution from SPI SI . 17
8 Implementation requirements . 17
8.1 Service provider implementation . 17
8.2 Device Implementation . 18
9 Client identification . 18
9.1 Introduction . 18
9.2 Client identifier format . 18
9.3 Client Identifier Presentation . 18
9.3.1 Introduction. 18
9.3.2 Use of TLS . 19
9.3.3 Protocol guidance . 19
9.4 Service provider reception . 20
Annex A (normative): Deriving the GCC for a service. 21
A.0 Introduction . 21
A.1 Deriving the GCC using ECC . . 21
A.2 Deriving the GCC without ECC . 21
Annex B (informative): Bibliography . 29
History . 30

ETSI
5 ETSI TS 103 270 V1.3.1 (2019-05)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European
Broadcasting Union (EBU), Comité Européen de Normalisation ELECtrotechnique (CENELEC) and the European
Telecommunications Standards Institute (ETSI).
NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body
by including in the Memorandum of Understanding also CENELEC, which is responsible for the
standardization of radio and television receivers. The EBU is a professional association of broadcasting
organizations whose work includes the co-ordination of its members' activities in the technical, legal,
programme-making and programme-exchange domains. The EBU has active members in about
60 countries in the European broadcasting area; its headquarters is in Geneva.
European Broadcasting Union
CH-1218 GRAND SACONNEX (Geneva)
Switzerland
Tel: [phone]
Fax: [phone]
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
6 ETSI TS 103 270 V1.3.1 (2019-05)
1 Scope
The present document defines the methodology for discovering an Authoritative FQDN for a radio service, including
discovery using DNS queries to radiodns.org, a root domain name server operated by RadioDNS. The present document
also defines the construction of a unique ServiceIdentifier parameter and bearerURI for a radio service.
This version includes the addition of client identification.
NOTE: Specifications for applications built upon the RadioDNS methodology can be found at
http://radiodns.org/developers/documentation/.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI EN 300 401: "Radio Broadcasting Systems; Digital Audio Broadcasting (DAB) to mobile,
portable and fixed receivers".
[2] ETSI ES 201 980: "Digital Radio Mondiale (DRM); System Specification".
[3] ETSI TS 102 386: "Digital Radio Mondiale (DRM); AM signalling system (AMSS)".
[4] National Radio Systems Committee NRSC-5-B:2008: "In-band/on-channel Digital Radio
Broadcasting Standard".
[5] ETSI TS 102 818: "Digital Audio Broadcasting (DAB); Digital Radio Mondiale (DRM); XML
Specification for Electronic Programme Guide (EPG)".
[6] IETF RFC 1035 (1987): "Domain Names - Implementation and Specification".
[7] IETF RFC 3761 (2004): "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)".
[8] IEC 62106:2015: "Specification of the Radio Data System (RDS) for VHF/FM sound broadcasting
in the frequency range from 87,5 MHz to 108,0 MHz".
[9] National Radio Systems Committee NRSC-4-B: "Specification of the radio broadcast data system
(RBDS)".
NOTE: Available at https://www.nrscstandards.org/standards-and-guidelines/documents/standards/nrsc-4-b.pdf
[10] ISO 3166-1: "Codes for the representation of names of countries and their subdivisions - Part 1:
Country codes".
[11] Void.
[12] ETSI TS 101 756: "Digital Audio Broadcasting (DAB); Registered Tables".
[13] IETF RFC 2818: "HTTP over TLS".
ETSI
7 ETSI TS 103 270 V1.3.1 (2019-05)
[14] IETF RFC 7235: "Hypertext Transfer Protocol (HTTP/1.1): Authentication".
[15] SY-IDD-1020s: "HD Radio™ Air Interface Design Description, Station Information, Service
Transport".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
Not applicable.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
application: means of enhancing an associated radio service, using an IP connection, with additional content,
functionality, or interactivity
authoritative FQDN: internet domain for a service provider
bearer: method of carriage of the service
bearerURI: unique identifier for the service to be used in SPI SI documents
char: single character
client identifier: non-unique identifier sent by a client to a service provider
hexadecimal: representation of a number in base-16 using the characters 0-9, a-f
nibble: four-bit aggregation, or half an octet
RadioDNS FQDN: internet domain constructed only for the purposes of querying DNS
service: radio service or data service
ServiceIdentifier: string that uniquely identifies a radio service within the scope of an Authoritative FQDN
service provider: organization providing RadioDNS Hybrid Radio applications
string: zero or more characters in the range 0-9, a-z
3.2 Symbols
Void.
ETSI
8 ETSI TS 103 270 V1.3.1 (2019-05)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AM Amplitude Modulation
AMSS Amplitude Modulation Signalling System
ASF Advanced Systems Format
CNAME DNS Canonical NAME record
DAB Digital Audio Broadcasting
DNS Domain Name System
DRM Digital Radio Mondiale
ECC Extended Country Code
EId Ensemble Identifier
FCC Federal Communications Commission
FIG Fast Information Group
FM Frequency Modulation
FQDN Fully Qualified Domain Name
GCC Global Country Code
HTTP HyperText Transfer Protocol
IBOC In-Band On-Channel
IP Internet Protocol
PI Programme Identification
RBDS Radio Broadcast Data System
RDS Radio Data System
SCIdS Service Component Identifier within a Service
SI Service Information
SId Service Identifier
SPI Service and Programme Information
SPS Supplemental Program Service
SRV DNS SeRVice record
TLS Transport Layer Security
TTL Time To Live
URI Uniform Resource Identifier
URL Uniform Resource Locator
VHF Very High Frequency
4 Introduction
It is possible to supplement uni-directional radio services with applications that can take advantage of bi-directional
communication using the IP protocol. These applications may enhance the radio services with which they are associated
with additional content or functionality, or enable interactivity.
Radio devices should be aware of what IP delivered applications are available for each radio service it receives.
Standardizing the methodology to locate these applications allows a manufacturer to support IP delivered applications
directly on the device.
The present document standardizes the methodology for locating the Authoritative Fully Qualified Domain
Name (FQDN) for radio services using the following radio systems: FM with RDS [8] or RBDS [9], DAB/DAB+ [1],
DRM [2], AM with AMSS [3], and IBOC [4].
The present document standardizes a methodology to locate applications based upon the existing DNS methodology [6].
A RadioDNS FQDN is created from known broadcast parameters, and DNS is used to resolve this RadioDNS FQDN to
a CNAME record containing the Authoritative FQDN for the service provider.
The basis for this methodology broadly follows that used to map E.164 format telephone numbers to domains [7].
The present document also standardizes how to locate the Authoritative FQDN without the use of DNS lookup.
The Authoritative FQDN for a service can be acquired through a series of processes, shown in figure 1.
The present document also standardizes how devices identify themselves when connecting to service providers.
ETSI
9 ETSI TS 103 270 V1.3.1 (2019-05)

Figure 1: Process to acquire Authoritative FQDN for a service
The service is also given a ServiceIdentifier parameter, which is unique within the scope of an Authoritative FQDN.
The service may also be given a bearerURI parameter, which allows location of the service when placed in an SPI SI
document.
Clause 5 describes how to resolve the Authoritative FQDN and construct the ServiceIdentifier and bearerURI for
broadcast radio services.
Clause 6 describes how to resolve the Authoritative FQDN and ServiceIdentifier and construct the bearerURI for
streaming radio services.
Clause 7 describes how to resolve the Authoritative FQDN and ServiceIdentifier from an SPI SI document.
Methods for discovery of the SPI SI document are defined in ETSI TS 102 818 [5].
5 Authoritative FQDN resolution, and ServiceIdentifier
and bearerURI construction for broadcast services
5.1 RadioDNS FQDN, ServiceIdentifier and bearerURI
construction
5.1.1 FM with RDS/RBDS
5.1.1.1 RDS/RBDS parameters
The FM system supports identification of a radio service through transmission of meta-data by using RDS [8] or
RBDS [9].
ETSI
10 ETSI TS 103 270 V1.3.1 (2019-05)
The parameters are defined in table 1.
Table 1: RDS/RBDS parameter description
Parameter Description Value Status
gcc
The Global Country Code (GCC) of the country of origin of the 3-char mandatory
service (see annex A). hexadecimal
pi
Received RDS/RBDS Programme Identification (PI) code. 4-char mandatory
hexadecimal
frequency
Frequency on which the service broadcast is received, formatted to 5-char string mandatory
5 characters in units of 100 KHz. Frequencies below 100 MHz shall
be supplied with a leading zero, for example 95,8 MHz would be
represented as "09580", 104,9 MHz as "10490".

NOTE: During the development of RadioDNS, it was permitted to compile the RadioDNS FQDN using the
ISO 3166-1 [10] alpha-2 country code as an alternative to the GCC. However, since the GCC can be
derived from location information and the PI code, only the GCC has been standardized.
5.1.1.2 Construction of RadioDNS FQDN
The RadioDNS FQDN for a VHF/FM service is compiled as follows:
...fm.radiodns.org
Some examples of RadioDNS FQDNs constructed from broadcast parameters are shown in table 2.
Table 2: Example of RadioDNS FQDN construction for RDS/RBDS
GCC PI Frequency RadioDNS FQDN
(MHz)
ce1 c586 95,8 09580.c586.ce1.fm.radiodns.org
de0 d1e0 103,9 10390.d1e0.de0.fm.radiodns.org

5.1.1.3 Construction of ServiceIdentifier
The ServiceIdentifier for a VHF/FM service is compiled as follows:
fm///
Some examples of ServiceIdentifiers constructed from broadcast parameters are shown in table 3.
Table 3: Example of RadioDNS ServiceIdentifier construction for RDS/RBDS
GCC PI Frequency RadioDNS ServiceIdentifier
(MHz)
ce1 c586 95,8 fm/ce1/c586/09580
de0 d1e0 103,9 fm/de0/d1e0/10390

5.1.1.4 Construction of bearerURI
The bearerURI for a VHF/FM service is compiled as follows:
fm:..
The element may be replaced by the asterisk ("*") character to signify any frequency. In this case the PI
code alone shall be used by the device to locate the source.
Some examples of FM bearerURIs constructed from broadcast parameters are shown in table 4.
ETSI
11 ETSI TS 103 270 V1.3.1 (2019-05)
Table 4: Example of RadioDNS bearerURI construction for RDS/RBDS
GCC PI Frequency RadioDNS bearerURI
(MHz)
ce1 c586 95,8 fm:ce1.c586.09580
de0 d1e0 103,9 fm:de0.d1e0.10390
ce1 c201 many fm:ce1.c201.*
5.1.2 Digital Audio Broadcasting (DAB/DAB+)
5.1.2.1 DAB/DAB+ parameters
The parameters are defined in table 5.
Table 5: DAB parameter description
Parameters Description Value Status
gcc
The Global Country Code (GCC) of the country of origin of 3-char hexadecimal mandatory
the service (see annex A)
eid
The Ensemble Identifier (EId) of the service 4-char hexadecimal mandatory
sid
The Service Identifier (SId) of the service 4- or 8-char mandatory
hexadecimal
scids
The Service Component Identifier within the Service 1-char hexadecimal mandatory
(SCIdS) of the service component
uatype
The User Application Type (UAtype) of the data 3-char hexadecimal mandatory for data
component components,
otherwise omitted
For data services (or data components of audio services) the uatype parameter is also mandatory.
5.1.2.2 Construction of RadioDNS FQDN
The RadioDNS FQDN for a DAB/DAB+ service is compiled as follows:
[.]....dab.radiodns.org
Some examples of RadioDNS FQDNs constructed from broadcast parameters are shown in table 6.
Table 6: Example of RadioDNS FQDN construction for DAB
GCC EId SId SCIdS UAType RadioDNS FQDN
de0 100c d220 0 0.d220.100c.de0.dab.radiodns.org
ce1 c18c cc86 0 0.cc86.c18c.ce1.dab.radiodns.org
ce1 c185 e1c00098 0 004 004.0.e1c00098.c185.ce1.dab.radiodns.org

5.1.2.3 Construction of ServiceIdentifier
The ServiceIdentifier for a DAB/DAB+ service is compiled as follows:
dab////[/]
The element is application specific. The inclusion of is mandatory for data services or
data components of audio services.
Some examples of ServiceIdentifiers constructed from broadcast parameters are shown in table 7.
ETSI
12 ETSI TS 103 270 V1.3.1 (2019-05)
Table 7: Example of RadioDNS ServiceIdentifer construction for DAB
GCC EId SId SCIdS UAType RadioDNS ServiceIdentifier
de0 100c d220 0 dab/de0/100c/d220/0
ce1 c18c cc86 0 dab/ce1/c18c/cc86/0
ce1 c185 e1c00098 0 004 dab/ce1/c185/e1c00098/0/004

5.1.2.4 Construction of bearerURI
The bearerURI for a DAB/DAB+ service is compiled as follows:
dab:...[.]
The inclusion of is mandatory for data services or data components of audio services.
Some examples of bearerURIs constructed from broadcast parameters are shown in table 8.
Table 8: Example of RadioDNS bearerURI construction for DAB
GCC EId SId SCIdS UAType RadioDNS bearerURI
de0 100c d220 0 dab:de0.100c.d220.0
ce1 c18c cc86 0 dab:ce1.c18c.cc86.0
ce1 c185 e1c00098 0 004 dab:ce1.c185.e1c00098.0.004

5.1.3 Digital Radio Mondiale (DRM)
5.1.3.1 DRM parameters
The parameters are defined in table 9.
Table 9: DRM parameter description
Parameters Description Value Status
sid
The Service Identifier (SId) of the service 6-char hexadecimal mandatory
appdomain
The application domain of the data component 1-char hexadecimal mandatory for data
components, otherwise
omitted
uatype
The user application type of the data component 3-char hexadecimal mandatory for data
components, otherwise
omitted
The SId value for DRM is intended to be suitably unique internationally so as to not require region identification.
5.1.3.2 Construction of RadioDNS FQDN
The RadioDNS FQDN for a Digital Radio Mondiale service is compiled as follows:
[.].drm.radiodns.org
Some examples of RadioDNS FQDNs constructed from broadcast parameters are shown in table 10.
Table 10: Example of RadioDNS FQDN construction for DRM
SId App Domain UAType RadioDNS FQDN
e1c238  e1c238.drm.radiodns.org
f07256 1 00d 00d.1.f07256.drm.radiodns.org
a13002  a13002.drm.radiodns.org

ETSI
13 ETSI TS 103 270 V1.3.1 (2019-05)
5.1.3.3 Construction of ServiceIdentifier
The ServiceIdentifier for a Digital Radio Mondiale service compiled as follows:
drm/[//]
Some examples of ServiceIdentifiers constructed from broadcast parameters are shown in table 11.
Table 11: Example of RadioDNS ServiceIdentifer construction for DRM
SId App Domain UAType RadioDNS ServiceIdentifer
e1c238  drm/e1c238
f07256 1 00d drm/f07256/1/00d
a13002  drm/a13002
5.1.3.4 Construction of bearerURI
The bearerURI for a Digital Radio Mondiale service is compiled as follows:
drm:[..]
Some examples of bearerURIs constructed from broadcast parameters are shown in table 12.
Table 12: Example of RadioDNS bearerURI construction for DRM
SId App Domain UAType RadioDNS bearerURI
e1c238  drm:e1c238
f07256 1 00d drm:f07256.1.00d
a13002  drm:a13002
5.1.4 AM Signalling System (AMSS)
5.1.4.1 AMSS parameters
The parameters are defined in table 13.
Table 13: AMSS parameter description
Parameters Description Value Status
sid
The Service Identifier (SId) of the service 6-char hexadecimal mandatory

The SId value for AMSS is intended to be suitably unique internationally so as to not require region identification.
5.1.4.2 Construction of RadioDNS FQDN
The RadioDNS FQDN for an AM service with AMSS is compiled as follows:
.amss.radiodns.org
5.1.4.3 Construction of ServiceIdentifier
The ServiceIdentifier for an AM service with AMSS is compiled as follows:
amss/
5.1.4.4 Construction of bearerURI
The bearerURI for an AM service with AMSS is compiled as follows:
amss:
ETSI
14 ETSI TS 103 270 V1.3.1 (2019-05)
5.1.5 IBOC
5.1.5.1 IBOC parameters
The parameters are defined in table 14.
Table 14: IBOC parameter description
Parameters Description Value Status
tx
Transmitter Identifier 5-char hexadecimal mandatory
Service broadcast identifier
cc
Country Code 3-char hexadecimal mandatory
Service broadcast country code
mId
The identifier for a multicast 1-char hexadecimal mandatory for
Supplemental Program Service (SPS) supplemental
channel services, otherwise
omitted
The tx value is the FCC facility code of the transmitter in the United States of America, or a unique identifier supplied
by the licensors of the IBOC technology in other places.
The cc value is the hexadecimal representation of the encoded country ID [15].
EXAMPLE: the value of cc for the United States of America is 0x292.
The mId is only defined if the bearer describes a Supplemental Program Service (SPS), defined as a supplemental
"multicast" service to the main service. For a bearer describing the Main Program Service (HD-1), this value is omitted.
For a bearer describing the first SPS channel (HD-2), mId shall be 2, for the second SPS channel (HD-3), mId shall be
3, and so on.
5.1.5.2 Construction of RadioDNS FQDN
The RadioDNS FQDN for an IBOC service is compiled as follows:
[.]..hd.radiodns.org
Table 15: Example of RadioDNS FQDN construction for IBOC
tx cc mId RadioDNS FQDN
07426 292 07426.292.hd.radiodns.org
07426 292 2 2.07426.292.hd.radiodns.org

5.1.5.3 Construction of ServiceIdentifier
The ServiceIdentifier for an IBOC service is compiled as follows:
hd//[/]
Table 16: Example of RadioDNS ServiceIdentifier construction for IBOC
tx cc mId RadioDNS ServiceIdentifier
07426 292 hd/292/07426
07426 292 2 hd/292/07426/2
5.1.5.4 Construction of bearerURI
The bearerURI for an IBOC service is compiled as follows:
hd:.[.]
ETSI
15 ETSI TS 103 270 V1.3.1 (2019-05)
Table 17: Example of RadioDNS bearerURI construction for IBOC
tx cc mId RadioDNS bearerURI
07426 292 hd:292.07426
07426 292 2 hd:292.07426.2
5.2 Resolution of Authoritative FQDN
The RadioDNS FQDN, constructed from the broadcast parameters, is used to acquire the Authoritative FQDN. Making
a DNS query with a RadioDNS FQDN will return a single CNAME record containing the Authoritative FQDN of the
service provider. If no CNAME is returned, then the service has not been registered.
EXAMPLE: Consider an FM service identified by the RadioDNS FQDN:
09580.c479.ce1.fm.radiodns.org
Using the nslookup tool would yield the following lookup result:
canonical name = rdns.musicradio.com
Therefore, for this service, the Authoritative FQDN is:
rdns.musicradio.com
The broadcast parameters should be continuously monitored. If any broadcast parameter changes (for example, a
change to the RDS/RBDS PI code), the process of resolving the Authoritative FQDN should be repeated using the new
broadcast parameters.
The TTL (Time To Live) parameters of the Authoritative FQDN shall be queried and respected.
Upon expiry of the TTL, the process of resolving the Authoritative FQDN shall be repeated.
If the Authoritative FQDN has changed, then all active applications shall be notified and each application shall repeat
its own process for connecting to resources using the updated Authoritative FQDN.
6 Authoritative FQDN and ServiceIdentifier resolution
and bearerURI construction for IP-streamed services
6.1 General
An Authoritative FQDN may also be provided for IP-streamed services, by sending the value as part of the in-stream
metadata of the IP stream. This is defined as the parameter fqdn.
Since no broadcast parameters exist for such services, an additional parameter is required to provide disambiguation so
that the particular RadioDNS application can determine the exact service being used. This is defined as the parameter
sid.
The sid shall be unique across all services using the same Authoritative FQDN for application discovery, with a
maximum character limit of 16 characters in the range [a-z][0-9]. The exact use of this parameter is specific to the
RadioDNS application being used.
For any streaming protocol where the fqdn and sid parameters are sent as in-stream metadata at regular intervals, the
values shall be monitored after they have been initially acquired. If these values are found to change at any point, the
old values will be deemed to have expired, and the process of resolving the Authoritative FQDN shall be repeated.
If the Authoritative FQDN has changed, then all active applications shall be notified and each application shall repeat
its own process for connecting to resources using the updated Authoritative FQDN.
ETSI
16 ETSI TS 103 270 V1.3.1 (2019-05)
6.2 Inclusion of parameters into stream metadata
6.2.1 Streaming transports
6.2.1.1 SHOUTcast
SHOUTcast uses a client-server model, with each component communicating via a network protocol that intermingles
audio or video data with metadata such as song titles and the station name. It uses HTTP as a transport protocol.
NOTE: Additional information is available from https://forums.radiotoolbox.com/viewtopic.php?t=74.
The parameters should be contained within the initial HTTP Response at the start of the stream, using the HTTP
response header icy-url, which has a defined usage within the SHOUTcast specification. Its value should be of the
form:
http:///
If a Service Provider wishes to also support the intended functionality of this parameter to provide a URL to a website,
it is recommended that HTTP requests to this URL are handled appropriately (such as delivering a web-page, or
returning an HTTP 302 response to re-direct the browser to an alternative URL).
6.2.1.2 ASF
Advanced Systems Format (ASF) is a container format that is part of the Windows Media framework. It typically
defines a payload containing multiple streams of data, e.g. audio and a metadata stream.
An additional stream shall be created, solely containing the fqdn and sid, declared as Custom Metadata using key/value
pairs for attributes with the following keys:
• radiodns-fqdn for the fqdn
• radiodns-sid for the sid
It is recommended that the values be programmatically specified as a null-terminated Unicode string, using the default
platform language.
NOTE: If using Windows Media Encoder, this can be entered in as Custom Metadata when setting up the stream.
6.2.1.3 Flash Audio
Flash Audio is a container format for audio and video streams.
The parameters shall be implemented as a non-persistent Remote Shared Object available on the URI of the Flash
Audio stream itself. The object shall be read-only for clients.
NOTE: Guidance is available from
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/SharedObject.html.
The object shall be named: radiodns
And have the following named string properties:
• fqdn for the fqdn
• sid for the sid
Clients shall listen for changes to these properties and update accordingly.
6.2.2 Metadata intervals
It is desirable that the client receives initial or updated parameters with as short a delay as possible. The cycle time of
the metadata parameters will directly affect the speed at which connecting clients can access applications.
ETSI
17 ETSI TS 103 270 V1.3.1 (2019-05)
It is recommended that service providers ensure that connecting clients receive the parameters within 5 seconds.
6.3 Construction of bearerURI
The bearerURI for an IP-based service is constructed from the URL for the stream source.
EXAMPLE: http://media-ice.musicradio.com/Capital
6.4 Construction of ServiceIdentifier
The ServiceIdentifier for an IP-based service is constructed as follows:
id//
7 Authoritative FQDN and ServiceIdentifier resolution
from SPI SI
An Authoritative FQDN may also be provided in an SPI SI document [5]. In this case, the fqdn and sid parameters (see
clause 6) are provided as attributes of the radiodns element:
• radiodns/@fqdn carries the fqdn
• radiodns/@serviceIdentifier carries the sid
EXAMPLE 1:
The methods by which the SPI SI document can be acquired for the service are specified in ETSI TS 102 818 [5].
The ServiceIdentifier when derived from an SI document is constructed as follows:
• id//
EXAMPLE 2: id/www.heart.co.uk/bristol
If the SPI SI document is either updated or expires through any applicable mechanism, the old parameters shall be
discarded, and the process of resolving the Authoritative FQDN shall be repeated.
If the Authoritative FQDN has changed, then all active applications shall be notified and each application shall repeat
its own process for connecting to resources using the updated Authoritative FQDN.
8 Implementation requirements
8.1 Service provider implementation
For broadcast services, a service provider shall support clause 5, Authoritative FQDN resolution for broadcast services.
In addition, for services transmitted via FM with RDS/RBDS or DAB, the service provider shall transmit the ECC via
RDS Group 1A or DAB FIG 0/9 respectively. For DAB or DRM services, the service provider may also support
clause 7, Authoritative FQDN resolution from SPI SI. For IBOC services, the service provider shall transmit the
Country Code and FCC Facility ID via the Station ID Number message (MSG ID = 0000). In the United States of
America, the FCC Facility ID shall be populated by the FCC facility code of the transmitter. Outside of the United
States of America, this shall be populated by a unique identifier supplied by the licensors of the IBOC technology.
For IP-streamed services, a service provider shall provide values for the fqdn and ServiceIdentifier parameters using at
least one of the following:
• clause 6, Authoritative FQDN resolution for IP-streamed Services;
ETSI
18 ETSI TS 103 270 V1.3.1 (2019-05)
• clause 7, Authoritative FQDN resolution from SPI SI.
8.2 Device Implementation
For broadcast services, a device shall support clause 5, Authoritative FQDN resolution for broadcast services. For DAB
or DRM services, the device may also support clause 7, Authoritative FQDN resolution from SPI SI.
For IP-streamed services, a device shall support the acquisition of values for the fqdn and ServiceIdentifier parameters
from at least one of the following:
• clause 6, Authoritative FQDN resolution for IP-streamed Services;
• clause 7, Authoritative FQDN resolution from SPI SI.
9 Client identification
9.1 Introduction
A service provider's application may wish to identify connecting clients by using a client identifier. This enables it to
provide a varying response to the client; for example, to provide more detailed or personalized responses to clients that
present a client identifier, and less detailed or more generic responses to clients that do not.
The exact details on what this can be applied to are defined in the specification for that particular application.
The service provider's application may signal support for client identification by defining specific SRV records, as
defined in the specification for that application.
The service provider shall return an error if it is determined that the presented client identifier is invalid or
unrecognized, and shall always return a valid response if no device identifier is provided.
The method of allocation, distribution and management of client identifiers by a service provider is not defined by the
present d
...