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

Justin Uberti <juberti@google.com> Mon, 14 November 2011 12:08 UTC

Return-Path: <juberti@google.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 312CC21F8F09 for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 04:08:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.912
X-Spam-Level:
X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 wTZTUq5JpNcd for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 04:08:21 -0800 (PST)
Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5505921F8F0C for <rtcweb@ietf.org>; Mon, 14 Nov 2011 04:08:21 -0800 (PST)
Received: by yenl11 with SMTP id l11so1504342yen.27 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 04:08:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=gdekSj0WP4eH6rlFo99vs/0vKgKf+b9fsRs0KEcAoWs=; b=iLaBjPuPMIhNv//4TEwlyalBZJtBYuXV7fKGBYTFTD23+W/QazWTLX/SOc1rer5uRR fwabqX2McWlhy21iN9Sw==
Received: by 10.50.41.196 with SMTP id h4mr23433140igl.42.1321272500711; Mon, 14 Nov 2011 04:08:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.41.196 with SMTP id h4mr23433132igl.42.1321272500611; Mon, 14 Nov 2011 04:08:20 -0800 (PST)
Received: by 10.231.194.134 with HTTP; Mon, 14 Nov 2011 04:08:19 -0800 (PST)
Received: by 10.231.194.134 with HTTP; Mon, 14 Nov 2011 04:08:19 -0800 (PST)
In-Reply-To: <CAD5OKxu_-+ZRsqpUBkFSj=tYtOKG0pK3JoQTZHwQGMuBCnp0Gw@mail.gmail.com>
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <CALiegfmf59jb4asUu9LA6YY_aMtKEnM1Wy34KbuLEn3_h1xBXA@mail.gmail.com> <CALiegfmM1PB=VAQjfh4rW3-3C8aumHdWy9nZxD0-BWBq9Kq_tg@mail.gmail.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <CALiegfkWnRT8m4S9pXTxuLsc-p_bhkG3d=PX3qgiFFt5gW5yfw@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>
Date: Mon, 14 Nov 2011 07:08:19 -0500
Message-ID: <CAOJ7v-1Ew-=NP-BQySS_sreDTn+v9mEY_89_G6MyR-Mxa8LhBg@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
To: Neil Stratford <neils@belltower.co.uk>
Content-Type: multipart/alternative; boundary=14dae934042b0ce88d04b1b0ba1c
X-System-Of-Record: true
Cc: "&lt,rtcweb@ietf.org&gt," <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 12:08:22 -0000

On Nov 14, 2011 7:48 PM, "Neil Stratford" <neils@belltower.co.uk> wrote:
>
> On Mon, Nov 14, 2011 at 11:07 AM, Justin Uberti <juberti@google.com>
wrote:
>>>>>>
>>>>>>
>>>>>> If two peers have negotiated a data channel, it doesn't make sense
to use DTMF at all.
>>>>>
>>>>>
>>>>> If a WebRTC capable media server is relaying media to the PSTN you
may still want to signal some kind of DTMF between the client and the media
server for onward relay. If the data channel is available, why not use it
for DTMF?
>>>>
>>>>
>>>> Why represent the DTMF in an alternate format, when the only thing
that cares about it wants it in RFC 4733?
>>>
>>>
>>> Only a SIP destination endpoint would want it in RFC 4733, a PSTN
endpoint is going to want it in-band in the media stream, which the
relaying media server from WebRTC to PSTN would likely do. (No SIP here.)
>>
>>
>> This is a RTP thing, not a SIP thing. The PSTN gateway will take RTP as
input, including RFC 4733 telephone-event.
>
>
> In my example the terminating WebRTC media server *is* the PSTN gateway.
There is no RTP beyond the gateway, just ISDN etc. In this case to get the
most reliable DTMF transport from the client to the PSTN I'd have to roll
my own DTMF transport over a DataStream, carry if over the signalling
channel, or accept the lossy RTP DTMF channel. In many cases this DTMF RTP
will be the only RTP sent in that direction - I'm often asked for the
ability to send DTMF without requesting microphone access permission for
information only IVR use cases.
>
> I'd prefer we didn't have a DTMF API and instead leave it up to the
developer to send over the signalling channel (the usual sync arguments
don't apply here if you are sending from an API), but if we do have an API
it makes sense to use the most reliable transport available to carry it.
>
>>> How today am I notified of a quality or resolution change in the
decoded incoming video stream? What I want to avoid is the use of an
external signalling mechanism to tell me this, so I can avoid the glitchy
resize-before-ready - I want to do it when the data really is at the new
resolution.
>>
>>
>> Agreed. The <video/> element has videoWidth/videoHeight properties, but
it doesn't appear that a callback exists to indicate changes, so we'll
probably need to make a new API here.
>>
>> Note though that no signaling is required for this case.
>
>
> I agree that no signalling is required, but I'm not sure that a simple
callback with width/height is enough to enable notification of quality
changes etc. I still think that to build telepresence/broadcast quality
systems we will need closer access to both codec parameters and codec state
changes.

I'm sure we will need to expose more info, but I think that should be
driven by specific requirements, like what you mention above.
>
> Neil