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

Harald Alvestrand <harald@alvestrand.no> Tue, 15 November 2011 09:56 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 839C211E80BC for <rtcweb@ietfa.amsl.com>; Tue, 15 Nov 2011 01:56:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.577
X-Spam-Level:
X-Spam-Status: No, score=-110.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 ztQg3Ger-WT4 for <rtcweb@ietfa.amsl.com>; Tue, 15 Nov 2011 01:56:00 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AC88D11E818E for <rtcweb@ietf.org>; Tue, 15 Nov 2011 01:55:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C4C1139E112 for <rtcweb@ietf.org>; Tue, 15 Nov 2011 10:55:56 +0100 (CET)
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 lGf6v35xcZee for <rtcweb@ietf.org>; Tue, 15 Nov 2011 10:55:56 +0100 (CET)
Received: from [130.129.22.244] (dhcp-16f4.meeting.ietf.org [130.129.22.244]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AB29D39E0A3 for <rtcweb@ietf.org>; Tue, 15 Nov 2011 10:55:55 +0100 (CET)
Message-ID: <4EC23729.8010506@alvestrand.no>
Date: Tue, 15 Nov 2011 17:55:53 +0800
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@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> <4EC1B7E5.2030708@skype.net>
In-Reply-To: <4EC1B7E5.2030708@skype.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [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 09:56:00 -0000

On 11/15/2011 08:52 AM, Matthew Kaufman wrote:
> (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>.
audio/t140?