Subject: Re: [rtcweb] Support for websockets

From: Matthew Kaufman <[email-masked]>
Date: Sun, 04 Sep 2011 20:12:57 -0700

On 7/26/2011 5:50 AM, Harald Alvestrand wrote:
> On 07/26/11 01:28, Avasarala, Ranjit wrote:
>> Hi all
>>
>> By when can we expect WebRTC code (Google code) to support Websockets?
> ...
> In this forum, it may be appropriate to describe exactly how you see 
> Websockets fitting in with the RTCWEB specification suite; so far, 
> it's seemed to be not very closely related.

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?

Matthew Kaufman

---

From: Christopher Blizzard <[email-masked]>
Date: Tue, 06 Sep 2011 10:16:56 -0700

On 9/4/2011 8:12 PM, Matthew Kaufman wrote:
> 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.
>

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Sep 2011 09:04:46 -0600

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:

>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 07 Sep 2011 17:26:26 +0200

> 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 w…
The huge difference between websockets and a real-time RTP connection is 
that in a real-time connection, you drop packets if you get behind. In 
websockets, you deliver everything that made it to the "send" call.

Apart from that, I think it's fine - it's got a "message" concept that 
can be used to tell packets apart; just shove each RTP packet into its 
own WS "message" and go. RFC 1006 did that back in the 1980s.
The extra cycles spent "masking" are irritating, but unlikely to be fatal.

Now, if the send buffers were controllable and visible, the sender side 
could emulate RTP by dropping the packets rather than calling "send()" 
when congestion occurs. Don't know if such interfaces exists.

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 07 Sep 2011 15:11:32 -0700

On 9/7/11 8:26 AM, Harald Alvestrand wrote:
>> 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.
> The huge difference between websockets and a real-time RTP connection 
> is that in a real-time connection, you drop packets if you get behind. 
> In websockets, you deliver everything that made it to the "send" call.

This is also true of TURN-over-TLS-over-TCP, as is in the current spec 
for the TCP fallback.

However TURN-over-TLS-over-TCP doesn't look like HTTP to firewalls that 
only allow HTTP traffic.

Matthew Kaufman

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 8 Sep 2011 08:26:20 +0300

On 9/7/11 6:04 PM, Cullen Jennings wrote:
> 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)
surprisingly enough it can transfer large high bandwidth files

/Sal