Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)

Tim Panton <tim@phonefromhere.com> Tue, 15 November 2011 08:32 UTC

Return-Path: <tim@phonefromhere.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 D797D21F8D7A for <rtcweb@ietfa.amsl.com>; Tue, 15 Nov 2011 00:32:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.558
X-Spam-Level:
X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 YF6F4D3uLWcN for <rtcweb@ietfa.amsl.com>; Tue, 15 Nov 2011 00:32:01 -0800 (PST)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 24E4821F8D74 for <rtcweb@ietf.org>; Tue, 15 Nov 2011 00:32:00 -0800 (PST)
Received: from [192.168.157.48] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 5879537A902; Tue, 15 Nov 2011 08:44:42 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <02485FF93524F8408ECA9608E47D9F2007CAE80647@nambx05.corp.adobe.com>
Date: Tue, 15 Nov 2011 08:31:55 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA321B61-CADA-4E36-B5E0-D4382FE09273@phonefromhere.com>
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <CABcZeBOiPxz_swdaG6Aqoch1WAUtjNh4eOQy1QObCDXT_B8azg@mail.gmail.com> <CAD5OKxtp+LQBRCHgbWdJyrSRcpNQ82i64TJgGtGPrE7+GKcEog@mail.gmail.com> <4EBC3475.90706@alvestrand.no> <CAD5OKxu_-+ZRsqpUBkFSj=tYtOKG0pK3JoQTZHwQGMuBCnp0Gw@mail.gmail.com> <CAD5OKxuaWJ3SBv+0gac6EQy6-Lsb-LS_SBXk5FqObKy4mN6wNg@mail.gmail.com> <CCF4FC92-D5AA-43C8-A0B2-8041C9B8E1BD@edvina.net> <CAD5OKxs-pWwDBjwAu=mQVWRZa4H_YPpzQ31=0qxUUj-pJOErcg@mail.gmail.com> <A2DFC694-DBDF-4DB4-8DE0-DD638C7AF2BE@acmepacket.com> <CALiegfkU1qhLmhY9L373pF7j9zwHipFfu4mAuY49RDTNL7V5Vg@mail.gmail.com> <C11CACFE-FE5A-43F2-8B61-6ABC9965B7FC@acmepacket.com> <CALiegfkehnLmWuqBPMRki=tJDTHmJ0e6M3RGX-mDBJNzcAA_DQ@mail.gmail.com> <FCFB9735-FB48-45C1-9ADF-CA6DBE5299B1@acmepacket.com> <CALiegfkstuyuRJWEvsU7EtHE5V41zavdrN0OZ1OSWtv022P16Q@mail.gmail.com> <4EC134F3.5070504@jesup.org> <CABRok6=E941kYiOfo7J3Vq8nG-SqE9kcJJw1rv3cVNeyVE8rmg@mail.gmail.com> <4EC13A91.901090 9@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CAE80647@nambx05.corp.adobe.com>
To: Michael Thornburgh <mthornbu@adobe.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)
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: Tue, 15 Nov 2011 08:32:01 -0000

On 14 Nov 2011, at 19:12, Michael Thornburgh wrote:

> in "those proprietary plugins" that nobody ever namesFlash, media streams have a generic data channel that is time synchronized to the media. calling the "send" method on a publishing-to-peers-or-server stream puts the current media timestamp on the message. at the subscriber end the callback associated with the message is called synchronized with the playback media clock.
> 
> this is useful for example when recording and playing back the non-media parts of an online meeting, such as text messages or slide changes, or insertion of cue points in media, or text captions, or etc.
> 
> in Those Proprietary Plugins That Must Not Be Named, the data channel of a stream can be fully reliable or partially reliable. the timing semantics for a time-synchronized data message is that it won't trigger its callback before its timestamp, but if it will trigger if it arrives late (which might happen for a fully reliable message).
> 
> -mike
> 

Not all proprietary plugins are Flash ;-) - We have a Java  applet that implements IAX - which ends up 
with similar properties - you can send and receive data (in a few formats although mostly we ended up
putting JSON in text) - the data is reliable, timestamped with the media time,  sequenced datagram (not a stream). Most usages ignore the media timestamp and just process it 'immediately' but on occasion the timestamp is useful.

Tim.