IETF Logo Mail Archive

Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 21 September 2011 12:10 UTC

Return-Path: <HKaplan@acmepacket.com>
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 442D321F8B73 for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 05:10:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level:
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599]
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 Hyep4xeTDxsE for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 05:10:14 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 961B521F8AF9 for <rtcweb@ietf.org>; Wed, 21 Sep 2011 05:10:14 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Sep 2011 08:12:20 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 08:12:20 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Colin Perkins <csp@csperkins.org>
Thread-Topic: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
Thread-Index: AQHMeFe1JM5xuK/2UEGsR/sv4LARig==
Date: Wed, 21 Sep 2011 12:12:20 +0000
Message-ID: <6295ADCD-BB33-4B8A-B6A9-01D3FC3E0FA8@acmepacket.com>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> <4E78A4FB.1050504@ericsson.com> <4E79AC33.4000900@alvestrand.no> <0075AB47-3DFF-4000-9057-CA0628DF711A@csperkins.org> <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.com> <8E8D4F16-AE3B-4E45-88C3-C795B0DE71A6@csperkins.org>
In-Reply-To: <8E8D4F16-AE3B-4E45-88C3-C795B0DE71A6@csperkins.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <C918F8FAF03ED54BA837A3896AB1065F@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
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, 21 Sep 2011 12:10:15 -0000

OK, makes sense.

-hadriel


On Sep 21, 2011, at 8:09 AM, Colin Perkins wrote:

> Yes, essentially (plus RTP over UDP for the media, of course).
> 
> Colin
> 
> 
> On 21 Sep 2011, at 12:45, Hadriel Kaplan wrote:
>> Just to make sure I'm on the same wavelength, you're talking about:
>> 1) Defining PseudoTCP over UDP (a la libnice and jingle) for stream-oriented reliable data delivery.
>> 2) Defining DDCP over UDP for message-oriented unreliable data delivery.
>> 3) Requiring the browser to implement and only expose those two options for the "data" stream type and not raw UDP, so that we can enforce congestion control of the data channel. (oh, and the option for it to be PseudoTCP/DTLS/UDP or DCCP/DTLS/UDP)
>> 
>> Correct?
>> 
>> -hadriel

v2.23.0 | Report a Bug | By Email