[RTW] Second screen, low-delay control channels (Re: BOF agenda uploaded to IETF servers)

[Harald Alvestrand]

On 02/15/11 15:40, Dan Brickley wrote:
> On 15 February 2011 15:10, Harald Alvestrand<harald at alvestrand.no>  wrote:
>> I've uploaded our preliminary draft BOF agenda to the IETF server:
>>
>> http://www.ietf.org/proceedings/80/agenda/rtcweb.txt
>>
>> Comments welcome!
> Hello, and de-lurking,
>
> I won't be able to attend the meeting, but I have a scoping question.
> Or rather, a hypothesis that RTC might facilitiate some TV related
> (second screen / remote control) scenarios. Perhaps the meeting would
> be an appropriate mechanism to get feedback on whether RTC is relevant
> to such use cases?
I'm not sure - to me it seems like second-screen applications need 2 
types of data:
- Media data from a server, which are pretty well served by current 
streaming-over-HTTP efforts
- Control data that go between the devices, which frequently could 
benefit from a direct link to keep latency down.

In this use case, we could easily imagine using the RTC-web channel 
establishment functionality, but not pass media over them. This could be 
appropriate/important for some home situations, such as "TV on fixed 
network, remote on WLAN network, phone on 3G".

What do others think? Should we add such a scenario to our (so far 
virtual) list of scenarios?
> Last week I attended W3C's "TV and Web" Workshop in Berlin.
> http://www.w3.org/2010/11/web-and-tv/
> There's a workshop report in preparation but the raw materials are
> linked from http://lists.w3.org/Archives/Public/public-web-and-tv/2011Feb/0007.html
>
> There were a number of presentations (including mine) on theme of
> using devices (smart phones, tablets) as "second screens", for remote
> control functionality, but also to provide additional information,
> interactivity, social functionality etc to accompany TVs and related
> media centre devices. I showed some work that used XMPP to provide
> such a communications channel, and Matt Hammond from the BBC showed
> their HTTP/REST-based efforts. In both cases, "second screen"
> scenarios have some familiar difficulties, and the RTC work was
> discussed as a potential effort that could address these problems.
>
> When using classic server-mediated XMPP, remote control apps suffer
> from latency. XMPP allows us to address devices logically, but its
> point-to-point use in LAN-local scenarios, or when the devices are on
> different networks, is relatively immature (although JINGLE and
> XEP-0174 show it growing in that direction).
>
> When devices expose TV services over HTTP (as in the BBC work) things
> are relatively simple so long as both devices are on the same LAN, but
> otherwise there are difficulties.
>
> There is interest in the W3C TV Interest Group community towards
> standardising something in support of "second screen" remote control
> TV / media centre scenarios. But also a healthy concern to avoid
> re-inventing wheels - hence this message.
>
> My small understanding of RTC is that you will be addressing nat
> traversal issues, and will likely have some kind of control channel
> for direct (non-server mediated) signalling between endpoints. I would
> be grateful for any help in understanding whether these pieces
> could/should/might be relevant to any hypothetical new "TV-style
> remotes" W3C work as sketched above.
>
> Thanks for any advice, and sorry that the requirement/scenario is
> sketchy, some of us are working to come up with a more detailed
> picture asap,
>
> cheers,
>
> Dan
>