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

[Ted Hardie]

On Tue, Feb 15, 2011 at 8:54 AM, Harald Alvestrand <harald at alvestrand.no> wrote:
> On 02/15/11 15:40, Dan Brickley wrote:
>>
>> On 15 February 2011 15:10, Harald Alvestrand<harald at alvestrand.no>  wrote:

>> 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.
>

Another way to check scope might be to start from the middle.  In this work,
we're largely assuming that a web server has a role in setting up communication
between or among devices.  In the 2nd screen use case, where is the web
server?  Is it embedded in one or more of the devices, or a service provided
externally?  I'm aware of some systems that use a web server external to
devices like blu-ray players to provide an updatable list of applications
available and links to the content those applications will consume, but those
players communicate with output devices and remotes locally.  Is that
similar to your
use case, or are you considering an embedded web server?



> 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?

It's interesting, but I am concerned about scope creep.  We see skype on
TVs now, as well web-accessible apps, so I have no problem seeing
TVs as devices participating in RTC-WEB applications.  But I suspect
this use case is going to depend a good bit on whether the phone on 3g
rendezvous
with the TV-based service depends on a non-local service, like the iTunes
family share system.

regards,

Ted Hardie

>>
>> 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
>>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>