Topic Construction for IP bearers

[Ben Poor]

Dear All,

I've been having a conversation with a member of the group regarding how the RadioVIS topic is constructed for situations where broadcast parameters are not available (e.g. IP bearers). They have a particular experience in providing services to smaller broadcasters in the world of streaming, and bought some great expertise when initially working out how to perform RadioDNS signalling over IP streams, specifically over Shoutcast.

Paying particular attention to Shoutcast, which can signal RadioDNS lookup parameter using in-band metadata in the form of a header in the initial stream HTTP response using the parameter: icy-url

This takes the form of:

http://<FQDN>/<ServiceIdentifier>

Where FQDN is the authoritative FQDN used to perform SRV record queries, and ServiceIdentifier used to disambiguate the particular service.

The advantage of using this method for Shoutcast is that it is compatible with existing processes, and widely available to encoders.  It also leaves that parameter to fulfil its original functionality of indicating a Website URL for that service. As long as you have both an HTTP server and a DNS server running on the FQDN you can  use the same for both purposes.

Of course, being a website URL this means that this has some value to the service provider in terms of how it is formatted. It may need to contain what is called a 'Vanity URL' - not meaning this is any insulting way. That is, you may need to think about how existing website URLs are constructed.

Consider the situation where the Service Provider hosts a RadioVIS service for two radio stations, each with a similar Vanity URL structure and similar genre of services: rock. Their website URLs may look like:

http://www.radiodog.com/rock

http://www.radiocat.com/rock

The two FQDNs are hosted by the same company and happen to point to the same DNS server, and so both may have an SRV record for RadioVIS that points to the same Stomp server.

This means that both services will be using the same topic on this server of:

/topic/id/rock

There are a couple of ways that this can be dealt with:

1. Use different ServiceIdentifiers

For instance, instead of rock, use rockdog or rockcat. This has implications on the Service Provider and the URLs they offer to their clients. Also may not be possible with legacy Website URL arrangements, etc. You could potentially use some kind of central redirector, but this would look awkward and may unecessarily expose the Service Provider to clients.

2. Use separate Stomp servers 

For instance, define either separate servers for each station or group, and point the SRV records to these separate Stomp servers. This could be the same physical server, with virtual domains, much like Apache can do for websites.

3. Namespacing within the topic

For instance, define the topic format as:

/topic/<FQDN>/<ServiceIdentifier>

Any clashes in ServiceIdentifer would be disambiguated by using the original FQDN.

I'd like to get any thoughts on the above, and any other solutions, in order to get a view on whether there is a need for change. We're on a fairly tight timescale as I need to keep the ratification train moving along.

Thanks,

Ben

ben....@radiodns.org

[Ben Poor]

Slight correction to example 3. The topic should be:

/topic/id/<FQDN>/<ServiceIdentifier>

Note that this is id and not ip

[Ben Poor]

Dear All,

We've now had a chance to think about this so I am going to be making a proposal based on the feedback I have received.

I propose we amend the RadioVIS draft specification to alter the topic construction for IP-based bearers (or anywhere where broadcast parameters are not available) as per option 3 below. That is, to have a topic format of:

/topic/id/<fqdn>/<serviceIdentifier>

Where FQDN is the Authoritative FQDN and serviceIdentifier is the Service Identifier - values given by the relevant section in the RadioDNS specification for discovery using IP bearers.

The addition of the FQDN to the topic format is primarily meant to support different Service Provider configurations, helping to disambiguate should identical serviceIdentifiers be used on the same RadioVIS server.

Any comments, suggestions welcome. As usual, if there is a lack of sustained objection by Monday 19th March the proposal will pass.

As an aside, I intend on releasing the latest, and hopefully final draft at this time.

Ben

On Wednesday, 7 March 2012 14:28:46 UTC, Ben Poor wrote:

[Kennet Andhersån]

Hi,

 

I have the Revo Axis, and asked Revo about RadioVIS on FM they answered: “RadioVIS is only supported in DAB and IR modes”, “IR” I suppose is internet Radio.

 

So my question is what topic construction are Revo Axis using since it not a standard yet, I do like to run some test? (Revo referred me to me to Frontier Silicon for specs)

 

Thanks!

/Kennet