PI Discovery and SRV Lookup

[Mike Pilone]

I'm not a DNS expert but I want to make sure I understand the basic process for PI discovery starting with an SI file "Placed in a defined location on the service website" (10.2.4).

1) The client pulls the SI.xml file from a well know location. For example, http://www.heart.co.uk/radiodns/spi/3.1/SI.xml.

2) For each service, they get the radiodns element which includes the FQDN and serviceIdentifier. For example, fqdn=www.heart.co.uk serviceIdentifier=bristol

3) The client does a SRV record lookup on the domain www.heart.co.uk to locate the SPI application.

4) The client makes a request to http://<host>:<port>/radiodns/spi/3.1/id/www.heart.co.uk/bristol/20160818_PI.xml

So my questions:

1) Is the path to the SI.xml in (1) required as part of the spec or just recommended? It seems like if the location is well known to the client the actual path shouldn't matter.

2) In (3), I assume the SRV service name is "radioepg" as described in (10.2.2) for locating the SI.xml from the FQDN. Is this assumption correct?

3) Is the URL in (4) constructed correctly? It is a little confusing to have a "serviceIdentifier" attribute in the radiodns element that is just a component in the construction of the "ServiceIdentifier" used in the PI URL.

I think that's it for now. I just want to make sure I'm not missing anything major.

Thanks,

-mike

[Andy Buckingham]

Hi Mike,

It’s probably easiest to clarify up front that your walkthrough isn't the intended primary use case of RadioDNS / SPI.

RadioDNS exists to allow a radio receiver to find that very first host (in your example heart.co.uk) from a seemingly unrelated set of information received over the air from the radio station. For example:

1. Radio tunes to FM 96.3 and receives over RDS a PI code 0xc36b

2. Client can then construct an FQDN from the parameters, 09630.c36b.ce1.fm.radiodns.org, and perform a lookup

3. From this lookup we get an authoritative FQDN, in this example rdns.musicradio.com

4. From this we can then discover the EPG/SPI application, we do this by building an SRV record to lookup. As defined in the spec, this is _radioepg._tcp.<fqdn> - so we get _radioepg._tcp.rdns.musicradio.com

5. This gives us the host and port - epg.musicradio.com:80

6. From this we can then build the URL to a PI or SI file, in the format http://<host:port>/radiodns/spi/3.1/SI.xml or http://<host:port>/radiodns/spi/3.1/<bearer>/<date>_PI.xml

For the bearer params in the PI URL, if you wanted the PI for the station being listened to (in our example FM 96.3) we’d build the URL as follows: http://epg.musicradio.com/radiodns/spi/3.1/fm/ce1/c36b/09630/20160818_PI.xml

Hopefully this explanation clears up your questions, please reply if anything still doesn’t make sense.

Andy.

--
--
You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to
radiodns-...@googlegroups.com
To unsubscribe from this group, send email to
radiodns-develo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-develo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew, Ben]

Oops. Looks like absolute radio (and indeed all of Bauer radio) has fallen behind spec with regards point 6.

I shall endeavor to fix. 

Thanks Andy.

Bauer Radio Ltd, part of the Bauer Publishing Group, is home to a growing
network of no.1 commercial radio stations in all major markets in the UK and the
no.1 commercial broadcaster in national digital radio.

The information in this email is intended only for the addressee(s) named above.
Access to this email by anyone else is unauthorised. If you are not the intended
recipient of this message any disclosure, copying, distribution or any action
taken in reliance on it is prohibited and may be unlawful. Bauer Radio Ltd and
or its subsidiaries do not warrant that any attachments are free from viruses or
other defects and accept no liability for any losses resulting from infected
email transmissions. Please note that any views expressed in this email may be
those of the originator and do not necessarily reflect those of this
organisation.

Bauer Radio Ltd, Company number: 1394141 (England and Wales),
Registered Office: Media House, Peterborough Business Park, Lynchwood, Peterborough, PE2 6EA

[Andy Buckingham]

Hi Ben,

Be sure to take a good look through the whole Hybrid SPI spec, it was a big piece of work to harmonise RadioEPG with the DAB EPG XML specification so there’s now a single spec with both IP and DAB delivery.

I’m not fully across all the changes, so be sure to chip in to the RadioEPG Developers list if you need any further assistance.

Also worth pointing out here, it’s encouraged to keep both the “legacy” RadioEPG endpoints and XML format active as well as the new, so that older clients continue to function.

Andy.

[Mike Pilone]

Thanks, Andy. We're looking at possibly using RadioDNS (really just the EPG spec) as a common format for distributing program metadata from the central national distributor (in this case the Public Radio Satellite System PRSS in the US) to local member stations and then allowing the stations to simply republish the same content (adjusted for their local schedules and possibly merged with local content). Using RadioDNS as a common format may make the redistribution simpler for stations but I want to make sure the use case of national distributor-to-stations can fit into the RadioDNS model without feeling too much like we're jamming a square peg in a round hole. 

It seems like the SI linked in an HTML document or placed in a known location would meet our needs as we're distributing over a private satellite link and not any of the officially supported transports. We can also publish the SI location to station/middleware developers so they know where to access it because we're not dealing with generic end user devices in this use case. We still get the benefit of service definitions, PI discovery, and the EPG format but we just skip the initial FQDN lookup from radiodns.org.

I'm happy to hear feedback if anyone has strong opinions for or against this idea.

-mike

radiodns-developers+unsub...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-developers+unsub...@googlegroups.com.

[Mike Pilone]

Andy,

You said the bearer is used in the PI URL but from my reading of ETSI TS 103 270 section 7, if the radiodns element is used the ServiceIdentifier is constructed as "id/<fqdn>/<sid>". That doesn't have any relation to the bearer(s) defined in the same service.

Then ETSI TS 102 818 section 10.3 says PI will be discovered at http://<host>:<port>/radiodns/spi/3.1/<ServiceIdentifier>/<date>_PI.xml. Again, the bearer isn't mentioned. I guess for FM, the construction of the ServiceIdentifier and bearerURI (sections 5.1.1.3 and 5.1.1.4) are related but when using the "radiodns" element in a service (section 7), there is no relation between the bearer URI and the ServiceIdentifier (although it makes sense to keep them similar if bearer URI is used at all).

In either case (radiodns element or FM resolution), it seems like the spec calls for the ServiceIdentifier to be used in the PI URL which means the forward-slash separated ID as opposed to the dot-separated bearerURI.

Does that make sense?

-mike

On Thursday, August 18, 2016 at 4:13:31 PM UTC-4, Andy Buckingham wrote:

[Andy Buckingham]

Hi Mike,

Thanks for the clarifications and it certainly sounds like a good idea to utilise the SPI SI and/or PI formats as a form of common interchange format. That’s very their original intention.

If you think about the hybrid “stack” as many layers built on top of each other, top-down:

* SPI application - internet-based application

* RadioDNS lookups - lookup of internet applications from broadcast params

* Broadcast platform - metadata transmitted within the broadcast feed

You can, legitimately, just take that top level and repurpose in the way you’re intending.

The original intention of the HTML document signalling an EPG was a way to enhance the spec so that schedule information for radio stations could be advertised in a “linked data” kind of way. The specifics of how this could be used were left up to the implementer, but it was proposed that a radio client could - in theory - offer the user an option to add a radio station by domain, e.g. user enters “capitalfm.com” and the client loads the HTML, parses for the header, finds the SI and then adds all the radio stations advertised within to the client. Much more user friendly than saying “add http://epg.musicradio.com/radiodns/spi/3.1/SI.xml” (!)

For your specific use case it would be good to know a bit more about what is ingesting or manipulating the content. Is it up to subscriber to implement their own systems or is a particular piece of software being written to do this? Is it just a case of how you make that configurable? Without knowing much about this, one easy way of conveying how to find stuff would be to just give a subscriber the host and port and explain it follows the spec.

e.g. “We run our service on epg.musicradio.com:80”

Following the spec, I know the SI will be at http://epg.musicradio.com/radiodns/spi/3.1/SI.xml

From that SI I could identify a service or services that this host provides content for, and use the RadioDNS element serviceIdentifier attribute to find their PIs, e.g.

http://epg.musicradio.com/radiodns/spi/3.1/id/www.capitalfm.com/london/20160821_PI.xml

Hope this helps.

Andy.

radiodns-develo...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-develo...@googlegroups.com.

[Andy Buckingham]

Hi Mike,

The ServiceIdentifier referred to in PI URLs is not the same as the one featured in the RadioDNS element in the SI. You’ll notice in TS 102 818 Section 10.3 it cross references TS 103 270 (the core RadioDNS specification).

In that document it details the construction of serviceIdentifier for each different broadcast platform, e.g.:

fm = fm/<gcc>/<pi>/<frequency>

dab = dab/<gcc>/<eid>/<sid>/<scids>

It’s actually the lookup FQDN prefix prior to radiodns.org reversed and dots converted to path separators to match the protocol. 

However, as you correctly identify in Section 7 you can *also* use the value given in the radiodns element in the SI file. This allows for non-broadcast (IP bearers), which match your intended use case. You’re correct in saying that they are made up of

id/<fqdn>/<serviceidentifier>

So if in the SI file http://epg.musicradio.com/radiodns/spi/3.1/SI.xml we found:

<radiodns fqdn=“www.host.org” serviceidentifier=“example”/>

We can assume that the PI file for today on this service might be located at:

http://epg.musicradio.com/radiodns/spi/3.1/id/www.host.org/example/20160821_PI.xml

I say might as it’s completely within spec for that URL to 404 indicated no schedule is available for that date on that service.

[Nick Piggott (RadioDNS)]

For the benefit of future thread browsers.

There was a confusion in early versions of TS 103 270 in the way service identifiers were described. This was rectified by a minor change to the language in the specification, and it was republished as version 1.2.1

This post explains - https://groups.google.com/forum/#!topic/radiodns-developers/g_QNKT2MBws

Nick