Re: [rtcweb] Support for websockets

Sooner or later, I do think we should talk about how to spoof RTP through firewalls that only allow HTTP traffic. Certainly websockets would be worth looking at but I suspect we will find that it was not designed for transfer of large high bandwidth material (like video) and that something similar but different is needed. 

On Sep 6, 2011, at 11:16 AM, Christopher Blizzard wrote:

> On 9/4/2011 8:12 PM, Matthew Kaufman wrote:
>> 
>> 
>> I think there's a legitimate question as to how transmission of media over TCP should work. I believe that the existing code bases all assume that if you get IP addresses, you use them; if you get IP addresses for TURN servers you talk to them over UDP and use TURN for relaying; and if you get IP addresses for TURNS servers you talk to them over TLS/TCP and use them for relaying. Therefore the only TCP transport is TURN-over-TLS-over-TCP.
>> 
>> Is that sufficient and reasonable, or should media-over-websockets (or something else) be how TCP transmission of media works?
> 
> It's important to note that WebSockets aren't raw sockets in the classic TCP or POSIX sense.  So a conversation about transmission of media over TCP doesn't really apply to WebSockets, exactly.  It's true that since WS is over TCP that it's reliable and ordered.  What would be interesting would be a discussion of how to take media data coming in over a WebSocket and feed it to a consumer that could display that media, as well as the reverse.  But an API discussion feels like something that's more that's something that belongs at the W3C.
> 
> If we wanted a standardized representation in WS that might happen here, but it's not something that's strictly required.  Well-built APIs to encoders and decoders could mean that it's up to page implementers to figure out how to package the data, manipulated by     JS.
> 
> --Chris
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb