Re: [rtcweb] non-media data

On Apr 12, 2011, at 1:40 , Tim Panton wrote:

> Although we should aim to limit scope, it is also a good plan to listen to experience in the field.
> Our experience is that direct, reliable, sequenced transmission of small messages between 
> endpoints hugely adds to the value of a web-embedded RTC component.
> 
> Typically these messages are intimately tied to events in the media engine (change of speaker,
> end of message playback, transcription or recording available). (dynamic media meta-data if you like)
> 
> They are used to change the visual state of the web page (via javascript) so that (for example) the 
> web displayed IVR prompts stay in sync with the audio.
> 
> Whilst all of these are achievable via a more circuitous route (mediaserver->signalingserver->webserver->long poll-> browser)
> the added latency will make the visual changes lag the audio which undermines the user experience.
> 
> The value in RTC-web isn't the realtime audio/video itself, it's the fact that it is an integral part of
> the web-page, that integration is aided by non-media data.
> Tim.
> 

OK, this is fine, but having arbitrary numbers of streams of arbitrary media types is different from designing chat sessions or file transfer as 'part of' the tool.

> 
> On 12 Apr 2011, at 08:19, Elwell, John wrote:
> 
>> It is always good to try to limit scope, and I think this is indeed a case where we can useful limit scope to RTP-based media (audio, video, real-time text...).
>> 
>> John
>> 
>> 
>>> -----Original Message-----
>>> From: rtcweb-bounces@ietf.org 
>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of David Singer
>>> Sent: 08 April 2011 19:19
>>> To: rtcweb@ietf.org
>>> Subject: [rtcweb] non-media data
>>> 
>>> 
>>> On Apr 8, 2011, at 4:56 , Harald Alvestrand wrote:
>>> 
>>>> 
>>>> - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"?
>>>> Congestion control is obviously needed - both for this and 
>>> for media, naturally.
>>>> 
>>> 
>>> My feeling is that we should not forget we're designing 
>>> something to sit in a browser or browser-like context.  We 
>>> *have* text chat tools, file upload and download tools, and 
>>> so on, today, working in browsers.  Yes, they typically go 
>>> through a server, and going point to point might be an 
>>> optimization.  But that's the rub; I don't think we should 
>>> spend a lot of time optimizing tools that are ancillary to 
>>> the core problem of doing real-time a/v between two users. If 
>>> someone wants to start a group looking at real-time 
>>> point-to-point text chat, well, OK, but I think it's a 
>>> distraction for us, at least initially.
>>> 
>>> David Singer
>>> Multimedia and Software Standards, Apple Inc.
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 

David Singer
Multimedia and Software Standards, Apple Inc.