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

Matthew Kaufman <matthew.kaufman@skype.net> Tue, 15 November 2011 00:52 UTC

Return-Path: <matthew.kaufman@skype.net>
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 9362F21F853A for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 16:52:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level:
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 x4-DkJ+fg3yU for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 16:52:58 -0800 (PST)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE9311E80D0 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 16:52:58 -0800 (PST)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id DE98A16F5; Tue, 15 Nov 2011 01:52:56 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=3u7Fog7ct0ys8O lhsMoZKmiB60I=; b=igREngzZ81/rqwLRr8XG6qbWzlRn5/UZXjfAaqDRKXqIPr slbgr0SXtuW5hmp06HDugQS/CZBpfmkwHdp4La12iLmrrBGpcIjG8NzVu7Npi6tW EDQNRORfuW4UH8RHtdmhYp6iN9/NKYU0FrskhS1Uqje+TNqSykVKGu+Qgyxxk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=ZR5NXjloooKdJn/9EFND+s 30mRSFNUNZZA6WeQmowq8m4VNo9C8X1qnpJE+DiZHQPIJtIZ1UPVZ5TaAYpEBvad v6QmqfkLkAqsCwGef9/O3cdT++2ledIj5RNViDgsXOBCJ0XFoXeCn7i28QBON2J1 goLaXaYMT8vaTijxroRDk=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id DD1357EB; Tue, 15 Nov 2011 01:52:56 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id B917D3506F05; Tue, 15 Nov 2011 01:52:56 +0100 (CET)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F2kx9KUjsBr; Tue, 15 Nov 2011 01:52:55 +0100 (CET)
Received: from dhcp-103b.meeting.ietf.org (dhcp-103b.meeting.ietf.org [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id 7537E3506E8F; Tue, 15 Nov 2011 01:52:54 +0100 (CET)
Message-ID: <4EC1B7E5.2030708@skype.net>
Date: Tue, 15 Nov 2011 08:52:53 +0800
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Neil Stratford <neils@belltower.co.uk>
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>
In-Reply-To: <CABRok6=E941kYiOfo7J3Vq8nG-SqE9kcJJw1rv3cVNeyVE8rmg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Randell Jesup <randell-ietf@jesup.org>, rtcweb@ietf.org
Subject: [rtcweb] Media Synchronization (Re: 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 00:52:59 -0000

(Editing the subject line, again, to note that we have strayed far far 
off the original topic)

On 11/14/11 11:47 PM, Neil Stratford wrote:
> 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?

This actually raises a higher-level question of whether or not it is 
possible to deliver arbitrary *synchronized* data alongside audio and 
video. There is an argument that this is the domain of something like 
"timed text track" and *not* a WebRTC-specific behavior of the side data 
channel we've been talking about.

I have an application that currently uses <that proprietary plugin we 
don't talk about> to deliver streaming audio along with timecode that 
can be displayed in-sync with the audio that I would love to run inside 
a browser without <that plugin>.

Matthew Kaufman