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

Michael Thornburgh <> Mon, 14 November 2011 19:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E96611E8363 for <>; Mon, 14 Nov 2011 11:13:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UZTP--YOk4B2 for <>; Mon, 14 Nov 2011 11:13:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C9D5F11E835E for <>; Mon, 14 Nov 2011 11:13:40 -0800 (PST)
Received: from ([]) by ([]) with SMTP ID DSNKTsFoXN5wakj/; Mon, 14 Nov 2011 11:13:40 PST
Received: from (inner-relay-4b []) by (8.12.10/8.12.10) with ESMTP id pAEJDVQB011190 for <>; Mon, 14 Nov 2011 11:13:31 -0800 (PST)
Received: from ( []) by (8.12.10/8.12.9) with ESMTP id pAEJDULV004072 for <>; Mon, 14 Nov 2011 11:13:31 -0800 (PST)
Received: from ([]) by ([]) with mapi; Mon, 14 Nov 2011 11:13:30 -0800
From: Michael Thornburgh <>
To: "" <>
Date: Mon, 14 Nov 2011 11:12:35 -0800
Thread-Topic: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)
Thread-Index: Acyi5lVqAMN5IejWRPii37dxAHowWQAF6Tsw
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Nov 2011 19:13:42 -0000

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).


-----Original Message-----
From: [] On Behalf Of Randell Jesup
Sent: Monday, November 14, 2011 7:58 AM
Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)

On 11/14/2011 10:47 AM, Neil Stratford wrote:
> On Mon, Nov 14, 2011 at 3:34 PM, Randell Jesup < wrote:
>     Note my other email I just sent - DTMF has a property not shared by
>     the data streams - media synchronization.  I won't repeat all the
>     arguments here, but there actually is a reason for delivering it in
>     a media channel, totally regardless of legacy.  For a greenfield
>     design, one *might* implement it as a separate media stream (m=
>     line), but even there I'm not sure I would mandate it be separated.
> How can we achieve the media synchronization in WebRTC? In a traditional
> RTC endpoint the DTMF comes from the same source as the media, in many
> cases it's actually taken from the media itself. However in WebRTC the
> only way to trigger a DTMF event is through an asynchronous Javascript
> function call, which is not synchonized to the media. Do we assume that
> the function call happens 'at about the right time' and take that as the
> current timestamp to use?

That speaks to the API needing tweaking - the JS app generally knows 
*when* (in realtime) the event occurred; it should pass that info in 
with the command to send it so the synchronized data can be correctly 
generated (along with the other timing info - duration or ongoing until 
told to stop).  ("When" could also include a special case for "now", 
defined as the current media clock position when the function call is 

Randell Jesup
rtcweb mailing list