³ÉÈËÂÛ̳

A quick posting about our involvement with the (IMDA). The organisation began in late 2008 and the ³ÉÈËÂÛ̳ is a .

We are seeing many devices that have been associated with traditional broadcasting methods starting to capitalise in the IP world to give listeners new experiences either not provided by, or that improve on, traditional broadcasting methods. We've seen a lot of activity recently around Internet Radio devices and the IMDA has released their setting out the functional features of these devices. The IMDA has also been working, in parallel, on some metadata guidelines.

I chair the IMDA's Metadata Working Group (MWG). We've been hard at work trying to specify how broadcasters, big or small, can expose their Internet Radio services in an agreed way - quite a challenge. Members include device manufacturers, aggregators of internet radio streams and broadcasters. It has been great to see the views from the different angles of the industry and see them working together for a shared purpose: to make the internet radio experience better for listeners.

Working for a broadcaster, I understand that in order to maximise the potential of our media we need to be able to support its delivery by exposing appropriate metadata - ranging from a completely low-level functional aspect, through to services experienced directly by the listener. Through the MWG we have been able to begin specifying how the industry could do this. Initially we've been focussing on how to identify a broadcaster's live internet streams. For example, how does the ³ÉÈËÂÛ̳ properly expose the various formats, transports and metadata of our live internet streams that would allow device manufacturers and aggregators to consistantly give our listeners the best experience through their Internet Radio device? It requires all those involved in the chain to be aligned to certain working practices, and perhaps standards.

It's early days yet, and the IMDA is reviewing existing standards to see if anything is suitable or could be extended - no point in re-inventing the wheel. They want to make sure that any hurdles to adoption for broadcasters are small or non-existent, so that broadcasters across the world are able to follow these guidelines and make their media available in the same way.

I should have an update in January about this.

For such a seemingly simple service, pushing out strings of text synchronous to our broadcasts can be a complicated process. LiveText, as it's commonly referred to, is available on FM, DAB, Freeview, FreeSat... and on the web.

The text itself is crafted by production staff in our systems and then we distribute it to these platforms. I specifically wanted to talk here about 'the web' - and our IP delivery mechanism for LiveText - what I call 'LiveText-via-IP'.

You may have noticed that LiveText appears on many of our national radio networks' web sites and we had it on the original Radio Player through a Flash client. When we started this a few years ago, it was an initial offering that would give us some feedback about how we should implement the service fully... and whether we should implement it at all!

Having collated all the feedback, and reviewed the delivery solution - we started to plan a new infrastructure.

Meanwhile - new services that also provide content synchronous to our broadcasts were being trialled - we have previously spoken about our Visualising Radio trials - you can see the parentage from the LiveText service. So delivering other media-types synchronously with our live streams is just as important.

What we needed was a way of implementing an infrastructure that could replace our existing LiveText-via-IP service, making sure we can deliver that and provide a system that is scalable and stable for new services.

Through a tendering process we eventually agreed on picking an open-source protocol and a company known for its expertise for server side implementations. We chose as the technology, and as the company. (XMPP used to be called Jabber, just in case you knew it by that name.)

Some of the considerations we had around this tender process:

• we wanted an open-source protocol, to allow anyone to be access it and where libraries for consuming the 'messages' were available in a
• if we were going to use open-source, then any development should give back to the community - in the end with ProcessOne's nodes any extensions are and XMPP protocol
• picking anything requires us to investigate the 'pedigree' of such a system - so we wanted something that had evidence of widespread deployment and scale of delivery (how many concurrent users can connect at once) - XMPP
• we also wanted some flexibility - so a protocol and server that would allow us to deliver what we need right now (simple text strings), and then grow with our ambitions - the XMPP protocol might seem a little bloated for delivering simple text strings, but as we develop the LiveText service over the next few years it allows us to, for example, mark up different languages, alternative messages for different clients/services. It also lets us provide new services using the same protocol - so the learning curve is lowered and hopefully reusability of code is improved.

So - where can you see this in action right now?

On the websites we have upgraded our Flash-based LiveText clients so they are consuming messages from our ejabberd services. Check it out on Asian Network's homepage.

Our Flash clients are built using the - an open source ActionScript library - we made some tweaks that we're feeding back to the XIFF developers.

There are currently two connection methods for our XMPP service - direct connection through sockets or via over port 80. If you are behind a firewall that blocks the XMPP ports then your client will connect using BOSH.

If you are using Firefox and have the installed - you can see some comms in the console. If you are behind a firewall which blocks our sockets you will also see activity in the network activity section in Firebug - showing the BOSH connection - just look for 'http-bind'.

We are now referring to our infrastructure solution as 'PushFeeds'. (We couldn't keep referring to them as 'a set of nodes of ejabberd that provides XMPP PubSub and BOSH' - just too lengthy to repeat all the time!)

Coming up - we are looking at other places to put LiveText-via-IP, whether on our websites or syndication locations. Also looking at devices on IP that could support this. And, of course, other services that could take advantage of push messaging like this - I'll take this opportunity to ask any ³ÉÈËÂÛ̳ Staff interested to check out our about the service.

Alan Ogilvie
Interactive Platform Producer, Audio & Music Interactive

Further information:

• - the XMPP PubSub specification
• - the company we worked with to setup our service
• - the XMPP BOSH specification
• are available in many common languages, if you don't want to write one from scratch.
• - the open source server technology behind our service, supported by ProcessOne
• - find out how feed into ejabberd development, or make use of the technologies
• - an internal page for ³ÉÈËÂÛ̳ staff to find out about the service. (Link only works from within the ³ÉÈËÂÛ̳ network)