Proposed RadioVIS specification update

[Robin Cooksey]

Hi All,

 

I’d like to start the process of thinking about an updated version of the RadioVIS specification – presumably version 1.2.  I’d like to discuss the scope of this first, before getting in to too much detail of the precise changes.

 

The updates that I’d like to start with include:

 

1) Various relatively minor clarifications to the existing functionality in version 1.1, which have already been discussed to some extent on the list.  This includes things like the character encoding and length of the TEXT messages, behaviour when the RDS PI code changes etc.

 

2) Additions to the functionality in line with the new categorised slideshow functionality in the proposed update to the DAB MOT SlideShow specification (v2.3.1 of TS 101 499).

This adds support for slides being tagged with a given category, which a user can then browse through, independently of the normal linear slide show.

The intention here would be to update RadioVIS with the same capabilities, to keep it in step with broadcast MOT slideshow

 

3) A new mechanism to help a broadcaster communicate to a receiver the relative priorities of RadioVIS and DAB MOT slideshow, if both are available, to help the receiver make a better informed decision about which one to use.

There’s already been some discussion in another thread about this – which I will start off again.

 

 

In addition, there are some other possible topics that have been mentioned from time to time.  If there’s any interest from anyone in looking further at these, then they can potentially be included in an update to the spec as well:

 

4) Clarifications around trigger time handling, and specification of time.  This probably depends on the “Application Time Synchronisation” work, which is being discussed on the RadioDNS developers list.

 

5) Authentication and personalisation of content, possible using some authorisation support separated out from RadioTAG.

 

6) SVG widgets – i.e. RadioVIS slides which are interactive

 

 

If anyone has any thoughts on these points, or has any other comments on things that they’d like to be considered for RadioVIS, please let me know.

 

Best regards,

Robin

 

 

 

Robin Cooksey
Principal Software Engineer
Frontier Silicon Ltd.
Dales Manor Business Park, Babraham Road, Sawston, Cambridge, CB22 3LJ, UK
Tel: +44 1223 497784, Fax: +44 1223 836761

http://www.frontier-silicon.com/

The Toumaz Group incorporates Frontier Silicon Ltd, Toumaz Healthcare Ltd and Toumaz Microsystems Ltd.

Frontier Silicon Ltd is a company registered in England and Wales with company number 4213838. Registered address: 137 Euston Road, London, NW1 2AA, UK.

[Ben Poor]

Hi Robin,

Thanks for starting this process - its good theres new stuff to add, and especially things that keep it current with whats happening elsewhere.

On the specific points raised:

2) Be interesting to see how this would work - are you proposing something like the inclusion of categories in the RadioVIS frame, mirroring the use of behaviour in MOT Slideshow?

4) Good point, and you remind me that this needs to pushed along a little bit faster. There are some good working prototypes out there, and they raise some good points about how time should be interpreted by specific RadioDNS applications, especially RadioVIS. It would be good to have at least something providing the right language in the next RadioVIS specification, if not a direct reference to a concrete synchronisation specification.

I'll have to revisit the postings on the other topics, but perhaps it might be good to get a phone conference or get-together to discuss these points?

Ben

[Robin Cooksey]

Hi Ben,

 

Thank you for your thoughts.

 

On your specific points:

 

2) [categorised slideshow] I haven’t looked into this in much detail yet, but I was thinking that it’s likely this can be addressed by adding new headers to the RadioVIS frame, which correspond to some of the new MOT parameters (similarly to how the TriggerTime is currently handled).  There are likely to be some details which need to be resolved though.

 

4) [time synchronisation] I completely agree that it would be good to at least have some updates to the RadioVIS spec on how time should be interpreted, and I’m assuming that this will primarily come from the Application Time Synchronisation work that started.  Is there anything else that we can do to push this forward?

 

I think it would be a great idea to have a call, or possibly even a face to face meeting to discuss this – perhaps in a couple of weeks time when I’ve had a chance to put together some more details.

 

Who would be interested in attending a call, or a face to face meeting to discuss possible changes for a next version of the RadioVIS specification?

 

Best regards,

Robin

[Alexander Erk]

Dear all,

Am 15.01.2013 um 12:44 schrieb Robin Cooksey <Robin....@frontier-silicon.com>:

> Hi Ben,
>
> Thank you for your thoughts.
>
> On your specific points:
>
> 2) [categorised slideshow] I haven’t looked into this in much detail yet, but I was thinking that it’s likely this can be addressed by adding new headers to the RadioVIS frame, which correspond to some of the new MOT parameters (similarly to how the TriggerTime is currently handled). There are likely to be some details which need to be resolved though.
>
> 4) [time synchronisation] I completely agree that it would be good to at least have some updates to the RadioVIS spec on how time should be interpreted, and I’m assuming that this will primarily come from the Application Time Synchronisation work that started. Is there anything else that we can do to push this forward?
>
> I think it would be a great idea to have a call, or possibly even a face to face meeting to discuss this – perhaps in a couple of weeks time when I’ve had a chance to put together some more details.
>
> Who would be interested in attending a call, or a face to face meeting to discuss possible changes for a next version of the RadioVIS specification?

I would be interested in joining a call regarding this topics.

Best regards

Alex

-------------------------------------------------------------------------------------------------------------------
Dipl.Inf (FH) Alexander Erk
Informationsdienste

Institut für Rundfunktechnik GmbH
Phone: +49 (0)89 / 323 99 - 282
Fax: +49 (0)89 / 323 99 - 200
Internet: www.irt.de

Research and Development Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
Floriansmuehlstraße 60, 80939 Muenchen, Germany
registration court Munich Commercial, Register No. B 5191
Managing Director: Dr. Klaus Illgner-Fehns

The information in this email and any of its attachments is intended solely for the addressees and is confidential. If you receive this message in error, please immediately notify the sender, destroy any copies and delete it from your computer system.
The contents may contain information which is confidential and may also be privileged. Any part of this email may not be used, disseminated, forwarded, printed or copied without authorisation.
Liability cannot be accepted for any statements, views or opinions made which are clearly the sender's own and not expressly made on behalf of any of the companies below.

[Andy Buckingham (RadioDNS)]

Hi Robin,

Apologies for the delay in getting back to you on this, but I have
another issue I'd be interested in seeing raised in the next round of
discussions.

Adding WebSocket as an official RadioVIS transport

One problem that has been encountered relatively frequently over the
time of the VIS project is the desire to implement a VIS client in a
browser, for example on a broadcasters website. This ultimately lead
to use establishing an official transport of VIS over long-poll/Comet
style HTTP. As most are likely aware this is a somewhat inefficient
use of HTTP. The web community began resolving the need for push
communication in their stack sometime ago with the introduction
websockets.

WebSockets are now relatively mature and are being used on major
websites today. WebSockets allow very similar communication to the
current Stomp transport, but with the added benefit of being supported
in modern web browsers. Due to the relatively simplistic nature I also
don't see Websockets being a significant hurdle to device
firmware/hardware implementations either.

I'm conscious of adding "yet another" transport to the spec, but I
consider this to be an improvement over Stomp and could ultimately be
a replacement for it as a long term goal (for example, in a v2.0
specification) once we'd seen wide scale adoption.

Thanks for your time.


Andy.

On 7 January 2013 14:22, Robin Cooksey

[Robin Cooksey]

Hi Andy,

Thank you for your suggestion.

My immediate concerns about adding a third official transport would be that it potentially fragments things even further - as there would be another choice to make about which protocols to implement (at both ends). There would be a danger of raising the bar to implementation further, by adding more transports that need to be implemented at once.

Having said that, I can see how it might solve problems that afflict browser clients (allowing real push messages), and clients currently using stomp (potentially getting through firewalls and proxies more easily). In fact, I guess if we were starting from scratch today - we'd be likely to pick WebSocket as a single protocol, rather than either Stomp or Comet style HTTP.

Am I right in thinking that RFC 6455 is where this is defined? I've had a quick look at this, and I agree that it's not likely to be a significant hurdle to embedded devices (not much more than Stomp), although it is a little more complicated, and would of course be one more thing that needs implementing (or porting) and testing.

Have you given any thought to what a RadioVIS transport would look like using WebSocket?
For example, would you attempt to pass the topic in as part of the opening handshake, or as an initial message sent from the client?
Would Stomp-style messages be used? Or some alternative format?

Does anyone else have any views on this?

Best regards,
Robin

> -----Original Message-----
> From: radiovis-...@googlegroups.com [mailto:radiovis-
> devel...@googlegroups.com] On Behalf Of Andy Buckingham (RadioDNS)
> Sent: 15 January 2013 12:44
> To: RadioVIS Developers
> Subject: Re: Proposed RadioVIS specification update
>

[Ben Poor]

Hi Robin,

Agreed that any alteration in the RadioVIS transports would put the burden
of change primarily on Device Manufacturers such as yourself. That being
said, I'm sure we could probably all agree that new technologies come in
an replace the ones already established, and this is something that
RadioVIS should be considering.

I confess I haven't looked deeply into Websockets, but we should
collectively give it a test to see how it could work. I would argue that
as well as seeing whether using it is technically feasible, consideration
should be give as to how easy it is for Broadcasters to implement, and how
it can easily fit within an existing technology stack built around HTTP.

Things like scaling, stability, range of platforms should be part of this
consideration before any final decision is made. Hopefully that¹s
something we can all contribute to.

If we're going to be meeting up at some point in the future, this would be
a great topic to discuss further!

Thanks,

Ben

On 18/01/2013 16:56, "Robin Cooksey" <Robin....@frontier-silicon.com>

The information in this email and any of its attachments is intended solely for the addressees and is confidential. If you receive this message in error, please immediately notify the sender, destroy any copies and delete it from your computer system.

The contents may contain information which is confidential and may also be privileged. Any part of this email may not be used, disseminated, forwarded, printed or copied without authorisation.

Liability cannot be accepted for any statements, views or opinions made which are clearly the sender's own and not expressly made on behalf of any of the companies below.

This is Global Ltd (6251684) / Global Radio Holdings Ltd (4077052) / Global Radio Ltd (923454) / Global Radio Services Ltd (3296557) / Global Talent Group Ltd (3601691) / Global Talent Management Ltd (4631297) / Global Talent Music Ltd (5522116) / Global Talent Publishing Ltd (3509421) / Global Talent TV Ltd (4506139) / Global Talent Records Ltd (8112796) / Global Talent Music Recordings Ltd (3598411) / Global Music Television Ltd (7103948) / Global Charities (4359098) Registered Office: 30 Leicester Square, London WC2H 7LA.

[Robin Cooksey]

Hi Ben,

Thank you for your thoughts.

I'm not sure it's true that the burden of change would be primarily on Device Manufacturers. I think if we were to add a third transport, we would have to give serious consideration to deprecating some of the older transports - possibly Comet - and I think we would also have to think carefully about how to describe which transports are mandatory.
Also, I think it would be reasonable to be fairly sure that a new transport would get significant take-up - and get widely deployed.

In any case, I agree it would be a good idea to experiment with Websockets to confirm whether they are a feasible solution - both on the broadcasters side, but also on the device side.

Best regards,
Robin


> -----Original Message-----
> From: radiovis-...@googlegroups.com [mailto:radiovis-
> devel...@googlegroups.com] On Behalf Of Ben Poor
> Sent: 22 January 2013 14:40
> To: radiovis-...@googlegroups.com
> Subject: Re: Proposed RadioVIS specification update
>
> Hi Robin,
>

> Agreed that any alteration in the RadioVIS transports would put the burden
> of change primarily on Device Manufacturers such as yourself. That being
> said, I'm sure we could probably all agree that new technologies come in an
> replace the ones already established, and this is something that RadioVIS
> should be considering.
>
> I confess I haven't looked deeply into Websockets, but we should collectively
> give it a test to see how it could work. I would argue that as well as seeing
> whether using it is technically feasible, consideration should be give as to
> how easy it is for Broadcasters to implement, and how it can easily fit within
> an existing technology stack built around HTTP.
>
> Things like scaling, stability, range of platforms should be part of this
> consideration before any final decision is made. Hopefully that¹s something
> we can all contribute to.
>
> If we're going to be meeting up at some point in the future, this would be a
> great topic to discuss further!
>
> Thanks,
>
> Ben
>

> On 18/01/2013 16:56, "Robin Cooksey" <Robin.Cooksey@frontier-

[Andy Buckingham (RadioDNS)]

On 18 January 2013 16:56, Robin Cooksey

<Robin....@frontier-silicon.com> wrote:
> Am I right in thinking that RFC 6455 is where this is defined?

Correct, that's the most recent stable spec, with support across
IE10+, Firefox 11+, Chrome 16+, Safari 6+, Opera 12.10+ etc.

> Have you given any thought to what a RadioVIS transport would look like using WebSocket?
> For example, would you attempt to pass the topic in as part of the opening handshake, or as an initial message sent from the client?
> Would Stomp-style messages be used? Or some alternative format?

As there's no specific problems (I'm aware of) with the current frame
messaging, I'd be tempted to tightly replicate what we send over
Stomp. Using the "URL" for the WebSocket to include topics etc. would
hit the same complications we did with Comet where a client will
likely want 2x or more topics (SHOW, TEXT etc.), so I would favour a
basic CONNECT/SUBSCRIBE frame on connection/handshake. Usual SHOW/TEXT
frames would follow.

On 23 January 2013 15:23, Robin Cooksey

<Robin....@frontier-silicon.com> wrote:
> I think if we were to add a third transport, we would have to give serious consideration to deprecating some of the older transports - possibly Comet - and I think we would also have to think carefully about how to describe which transports are mandatory.

I don't think it would be wise to drop Comet. Comet is very useful as
a baseline implementation that mitigates problems in the other
protocols we've discussed (Stomp doesn't work in a browser, WebSockets
are still not "universal" and may experience issues across proxies).

Some may argue that we *just* use Comet. It's very "hardy" and works
in nearly all environments. It also allows a very basic "static"
implementation by design. Arguments against include increased message
overhead (>50% of a message over Comet is HTTP overhead) and a
perception (right or wrong) that long/frequent polling is a less
efficient mechanism versus full duplex socket based transactions.

I guess the ultimate question is if anyone cares sufficiently either
way to upset the status quo? I certainly think we need to do something
to make the implementation of a transport that "just works" in a
browser mandatory and clear for new adopters. Whether that simply
means dropping Stomp in favour of Comet, or alternatively dropping
Stomp and adding WebSockets, I'm not sure.

Does anyone else have an opinion on these suggestions?


Andy.


On 23 January 2013 15:23, Robin Cooksey

[Paolo @ RadioDNS]

Hi Andy and all,

Il 25/01/2013 17:01, Andy Buckingham (RadioDNS) ha scritto:
> I don't think it would be wise to drop Comet. Comet is very useful as
> a baseline implementation that mitigates problems in the other
> protocols we've discussed (Stomp doesn't work in a browser, WebSockets
> are still not "universal" and may experience issues across proxies).

My opinion is that a basic option based on a standard and (currently)
pervasive transport protocol is necessary. HTTP Comet seems to be this
option. Maybe it could also enable future integrations we're not aware
of now. It's not optimal of course, but are a few bytes more in each
message really a problem?

Kind regards
Paolo

[Boštjan Jerko]

Hi Andy,

Some time ago I played with the RadioVIS and EPG and open source Airtime radio station software.

I've created a server managing to show RadioVIS stream by using HTTP and Stomp message broker (coilmq).

Mind you I have put that to side since I didn't find any customers willing to fund further development, but the source code is open sourced on https://github.com/japina/RadioVIS_EPG

Regards,

Boštjan

----

homepage: http://www.japina.eu

Kronokraktor iphone app: http://itunes.com/apps/kronokraktor

Kronokraktor: http://www.kronokraktor.com

val202igra: http://www.t-42.eu/val202igra

hackshackers:  http://www.hackshackers.si

[Ben Poor]

+1 to all of that, if we were to deprecate anything I would guess it to be
Stomp. Stomp has been really good to kickstart RadioVIS and easy to
implement, but it might be time to look to the future.

Comet has the massive advantage of just being HTTP which is going to be
the most supported and supportable technology one can use for this. The
only downside is that it is a client-initiated process, driven by an
initial HTTP request from the client rather than pushed from the server.
That being said, things have moved on and this way of doing things is much
more scalable these days.

Always good to see how new things work, so a Websockets trial would be
interesting. I'd be happy potentially setting up a test instance for
people to see how it may work.

Ben

>--
>You received this message because you are subscribed to the Google Groups
>"RadioVIS developers" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to radiovis-develo...@googlegroups.com.
>For more options, visit https://groups.google.com/groups/opt_out.

[sem...@pqp.de]

Hi Paolo and all,

please read this comparison HTTP vs. websocket
http://www.websocket.org/quantum.html

Excerpt: "[...]
Let's take a look at the network throughput for just the HTTP request and response header data associated with this polling application in (three) different use cases."
(871 bytes)

Use case B: 10,000 clients polling every second: Network throughput is (871 x 10,000) = 8,710,000 bytes = 69,680,000 bits per second (66 Mbps)

vs. 2bytes

Use case B: 10,000 clients receive 1 message per second: Network throughput is (2 x 10,000) = 20,000 bytes = 160,000 bits per second (0.153 Mbps)
[...]"

And this is only signalling [speaks: GET That slide via this URL ...].

But think of the burst that follows: 10.000 x http://maschine/slide.png?cachebuster=10293847565

10,000 x 25kbyte = GB-interfaces on maschines

$ open calc
;)

keywords: CDR - Committed Data rate, burst price per MBit, unlimited -n, sockets, freemium


regards
Matthias

seems so...

Kind regards
Paolo

-- 
Matthias Semrau

PQP - IP Solutions
Stader Straße 107
D-28205 Bremen
0049-421-43 46 07
sem...@pqp.de
www.pqp.de
www.backend-systems.net
www.MyRadioDNS.com

Wichtige Hinweise für Geschäftskorrespondenz/
Important notes for business correspondence:
http://www.pqp.de/disclaimer.html

[Paolo]

Hi Mathias,
thank you for the feedback. I'm going to tell you my personal opinion. Websockets are a great option for the future, and maybe also for now. Count me in for that and to build/test a prototype.

However http is universally supported and enables (quick) integration with a plethora of services/platforms, at the expense of some overhead. And here we have the speed of internet, so the process of natural selection of the best protocol should work well.

Last thing, the figures you reported are impressive, but they come from a different scenario (e.g. frequently changing stock prices) or a continuous polling architecture. For http comet based radioVIS a long polling choice is preferable and typical settings could be 1 message every 20s. Maybe also cache can help reducing the overhead (as it's a REST request). When images will be requested, the burst comes from the payload, which is the same as websockets AFAIK.

Kind regards
Paolo

[Ben Poor]

Yup, essentially the bandwidth requirements are not going to be wildly different between HTTP and Websockets (presuming a sensible payload is used).

I would imagine most Broadcasters do not rotate slide content more frequently than 8-10 seconds, and most would be less than this.

Bursts of request for images are a result of 1000s of clients requesting images at the same time, regardless of the means of signalling the new images, and this can be smoothed out in either HTTP, Stomp or Websockets by spreading the time over which clients are notified.

Paolo is right that out of the 3 transports, HTTP is most well-known and well-supported, and that has to be the primary factor for both Broadcasters and Device Manufacturers.

Ben

From: Paolo <p.casa...@gmail.com>
Reply-To: "radiovis-...@googlegroups.com" <radiovis-...@googlegroups.com>
Date: Monday, 4 February 2013 18:47
To: "radiovis-...@googlegroups.com" <radiovis-...@googlegroups.com>
Subject: Re: Proposed RadioVIS specification update

[Pete Redhead]

Hi all,

After reading the email from Mathias above, I decided to do a quick comparison between Comet and Web Sockets using data from a live RadioVIS service. The PDF attached contains all the details, but the bandwidth savings do not appear to be that significant.

Web Sockets are an intersting possibility, and worth investigating for the future, I do worry what impact a third transport method would have on terms of fragmentation and perception.

Thanks,
Pete

[Robin Cooksey]

Hi All,

 

Thank you for all your thoughts and discussion on RadioVIS transports, and particularly the detailed investigation from Pete.

 

My feeling is that if we were starting from scratch, then it would make sense to consider basing a “browser-friendly” transport on WebSockets.

However, it doesn’t sound like WebSockets would have sufficient advantages over the existing Comet RadioVIS transport to be worth the complexity and potential confusion of adding a third transport.

 

That’s not to say that it’s not worthy of further investigation and experimentation, but I think it’s difficult to see a compelling justification for adding it as a third official transport in the short term.

 

Does anyone strongly disagree?

 

I also think it’s too soon to even consider deprecating Stomp, as the current RadioVIS specification advises that both servers and receivers are “strongly recommended” to implement Stomp, and there are significant numbers of devices out there that support just Stomp.

 

Best regards,

Robin

[Andy Buckingham (RadioDNS)]

> I also think it’s too soon to even consider deprecating Stomp, as the
> current RadioVIS specification advises that both servers and receivers are
> “strongly recommended” to implement Stomp, and there are significant numbers
> of devices out there that support just Stomp.

If we agree that dropping Stomp is a good long term goal, could I
suggest we make it mandatory to support both as a bridge between the
current standing and our long term goal? We can then take stock of the
state of adoption at a later date and deprecate Stomp, before removing
it.


A


On 5 February 2013 11:23, Robin Cooksey

[Ben Poor]

Hi All,

Placing my Global Radio hat on my head, we are interested in altering the RadioVIS specification in order that the HTTP transport is seen as the 'primary' transport for RadioVIS. 

Whilst this has no special meaning within RadioVIS, it would be useful if the HTTP transport were to appear *before* the Stomp transport within the specification document, and guidance given for Broadcasters and Device Manufacturers setting out the benefits/disadvantages of both. The reason for this is that we see more advantages in implementation of the HTTP transport.

Whilst we perhaps dont need to explicitly mark Stomp as being 'deprecated', I do think it would be useful to decide whether this is something that we would need to do at some point in the future, and to put a timescale on any work needed to confirm that.

I think maybe discussing this further on a call would be a good thing, along with all the other changes you have proposed, Robin. Do you want to fix up a date/time for this? I'm pretty flexible.

Thanks,

Ben

[Robin Cooksey]

Hi Ben,

 

Thank you for the suggestion.

 

I wonder if you could expand a bit further on what you think the benefits and advantages of the HTTP transport are?

 

Hopefully other people will correct me if I’m wrong, but currently I believe that most current live RadioVIS services support only Stomp, and there’s only one broadcaster that I know of that supports HTTP as well.

Also, I think all general receivers that support RadioVIS support Stomp only.

 

If we’re to further promote the HTTP transport, then I wonder how we’d make sure that we don’t end up with fragmentation, where some receivers only support some broadcasters, and other receivers only support some other broadcasters?

 

I think it would be a good idea to have discuss this (and the other proposed changes) on a call at some point – but I think it might be useful to discuss this a bit further on the list first, and then agree an agenda for a call, maybe in a few weeks time.

 

Best regards,

Robin

 

 

From: radiovis-...@googlegroups.com [mailto:radiovis-...@googlegroups.com] On Behalf Of Ben Poor
Sent: 04 March 2013 12:06
To: radiovis-...@googlegroups.com
Subject: Re: Proposed RadioVIS specification update

 

Hi All,

[AlexErk]

Hello Robin, dear all,

2) Additions to the functionality in line with the new categorised slideshow functionality in the proposed update to the DAB MOT SlideShow specification (v2.3.1 of TS 101 499).

This adds support for slides being tagged with a given category, which a user can then browse through, independently of the normal linear slide show.

The intention here would be to update RadioVIS with the same capabilities, to keep it in step with broadcast MOT slideshow

Proposal: 

We could use the header mechanisms in both (HTTP and STOMP)  with optional headers to support this:

 

STOMP in the message hearder or  in the JSON response for HTTP:

category_slideid: 0xXXXX (to bytes )

category_title:  UTF-8 String (max. 128 bytes)

The URL already exists, and the alternative URL in the Cat.SLS Spec does not make sense in my point of view, because we're IP only.

RadioVIS does not know the concept of MOT Update. But we could define, that if a Message for the same slide (Image URL) is send wit different headers, this is handled as an update of this content. 

 

 

3) A new mechanism to help a broadcaster communicate to a receiver the relative priorities of RadioVIS and DAB MOT slideshow, if both are available, to help the receiver make a better informed decision about which one to use.

There’s already been some discussion in another thread about this – which I will start off again.

This is a absolute desirable feature for broadcasters.

So far for now

Best regards

Alex