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

Neil Stratford <neils@belltower.co.uk> Mon, 14 November 2011 15:47 UTC

Return-Path: <neils@vipadia.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 2814611E810B for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 07:47:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.929
X-Spam-Level:
X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 HQR3P8vMyxfo for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 07:47:14 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2C11E80BA for <rtcweb@ietf.org>; Mon, 14 Nov 2011 07:47:14 -0800 (PST)
Received: by iaeo4 with SMTP id o4so9514331iae.31 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 07:47:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.20.201 with SMTP id g9mr5234204ibb.57.1321285632005; Mon, 14 Nov 2011 07:47:12 -0800 (PST)
Sender: neils@vipadia.com
Received: by 10.231.207.10 with HTTP; Mon, 14 Nov 2011 07:47:11 -0800 (PST)
In-Reply-To: <4EC134F3.5070504@jesup.org>
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <CAD5OKxvQYVKOZF88WLCiRseg-qXQdOpKeDU_t9b-yA2GcDBT-w@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>
Date: Mon, 14 Nov 2011 15:47:11 +0000
X-Google-Sender-Auth: j74loYVKiP7ajEKLqOGqGOcGPHY
Message-ID: <CABRok6=E941kYiOfo7J3Vq8nG-SqE9kcJJw1rv3cVNeyVE8rmg@mail.gmail.com>
From: Neil Stratford <neils@belltower.co.uk>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: multipart/alternative; boundary=0015175ce0d8be187004b1b3c8d7
Cc: 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: Mon, 14 Nov 2011 15:47:15 -0000

On Mon, Nov 14, 2011 at 3:34 PM, Randell Jesup <randell-ietf@jesup.org>wrote;wrote:

> On 11/14/2011 4:53 AM, Iñaki Baz Castillo wrote:
>
>> But DTMF was the topic of the email.
>>>
>>
>> RTP/SRTP is unreliable so sending like-reliable information (DTMF's)
>> over an unreliable stream is, for sure, not the best design. In WebRTC
>> such reliable info could be sent over signaling or over the
>> data-channel (both of them reliable). Why to choose the worst option?
>> reply: to interoperate with existing VoIP protocols.
>>
>
> 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?