³ÉÈË¿ìÊÖ

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)