Re: [rtcweb] Support for websockets

Harald Alvestrand <harald@alvestrand.no> Wed, 07 September 2011 15:24 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9647221F8AF1 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 08:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.639
X-Spam-Level:
X-Spam-Status: No, score=-107.639 tagged_above=-999 required=5 tests=[AWL=2.960, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMzYwhPcXJK4 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 08:24:43 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D27FF21F8AF3 for <rtcweb@ietf.org>; Wed, 7 Sep 2011 08:24:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 25D5D39E112 for <rtcweb@ietf.org>; Wed, 7 Sep 2011 17:26:28 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aTwNwXm1Q2U for <rtcweb@ietf.org>; Wed, 7 Sep 2011 17:26:26 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C6EEF39E072 for <rtcweb@ietf.org>; Wed, 7 Sep 2011 17:26:26 +0200 (CEST)
Message-ID: <4E678D22.4060203@alvestrand.no>
Date: Wed, 07 Sep 2011 17:26:26 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> <BLU152-W38359A17A67825B59CD5D0934C0@phx.gbl> <4E27BE02.7090606@ericsson.com> <9F9278CB1892FB48BF35CB5CC3992478A5395C720E@HKGMBOXPRD01.polycom.com> <4E2EB82C.30709@alvestrand.no> <4E643E39.8020205@skype.net> <4E665588.5000700@mozilla.com> <F2636DC8-94B1-4C17-8A82-B4ED745C913E@cisco.com>
In-Reply-To: <F2636DC8-94B1-4C17-8A82-B4ED745C913E@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Support for websockets
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Sep 2011 15:24:43 -0000

On 09/07/11 17:04, 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) 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.

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.