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

Neil Stratford <neils@belltower.co.uk> Mon, 14 November 2011 10:16 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 438E721F8CCB for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 02:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.916
X-Spam-Level:
X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ssTg3e7H9y42 for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 02:16:34 -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 62A9B21F84F5 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 02:16:34 -0800 (PST)
Received: by iaeo4 with SMTP id o4so9130754iae.31 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 02:16:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.20.201 with SMTP id g9mr5034857ibb.57.1321265793804; Mon, 14 Nov 2011 02:16:33 -0800 (PST)
Sender: neils@vipadia.com
Received: by 10.231.207.10 with HTTP; Mon, 14 Nov 2011 02:16:33 -0800 (PST)
In-Reply-To: <CAOJ7v-3W36MGn+8UDo3C2WWtnzJQ4GcB8qkoXy5zucJxjmF1zw@mail.gmail.com>
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <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> <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> <CAOJ7v-3w4t0oYKs+01srAmPGziYt6vVZNOQwbpZ7YWUFZtP20w@mail.gmail.com> <CABRok6mJx+quBzdzRZ8fX774+kj-ABWJJvPB=P7=7R5s=ZA2Yg@mail.gmail.com> <CAOJ7v-3W36MGn+8UDo3C2WWtnzJQ4GcB8qkoXy5zucJxjmF1zw@mail.gmail.com>
Date: Mon, 14 Nov 2011 10:16:33 +0000
X-Google-Sender-Auth: VzylS_-EJCkPa1bgruDmF_eJVIk
Message-ID: <CABRok6nYi4tg1wJt=0xbw6tkp8JDT4FEpxgW=Uhovx=j+w3=bA@mail.gmail.com>
From: Neil Stratford <neils@belltower.co.uk>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary=0015175ce0d84b2b5c04b1af2a00
Cc: "<rtcweb@ietf.org>" <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 10:16:35 -0000

On Mon, Nov 14, 2011 at 9:13 AM, Justin Uberti <juberti@google.com> wrote:
>
> On Mon, Nov 14, 2011 at 3:39 AM, Neil Stratford <neils@belltower.co.uk>wrote;wrote:
>
>> On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti <juberti@google.com>wrote;wrote:
>>
>>>
>>> As a non-"telco" participant in this WG, I strongly agree with this.
>>> DTMF has a clear upside (support for PSTN) and no downside other than the
>>> need for a new API method.
>>>
>>
>> This is my concern, that we are proposing a codec specific API method
>> when we have ruled out exposing APIs for other codecs.
>>
>> If two peers have negotiated a data channel between them it doesn't make
>> a lot of sense to send DTMF over RTP, it should be carried over the
>> reliable data channel. So if we do expose an API for sending tones, can it
>> be done in such a way that it can be carried using whatever the most
>> appropriate transport is? (obviously without requiring any javascript
>> changes - because we can't expect javascript developers to upgrade)
>>
>>
> 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? Should the DTMF API only be for RFC4733 and not any other
transport?


> Regarding whether this API should be extended to be a generic codec API, I
> think it should be obvious that the ability to send one of 12 well-defined
> signals in a standardized manner is orders of magnitude simpler than the
> configuration options available for modern video codecs.
>

I still see a benefit in exposing codec parameters, and in providing codecs
with the ability to generate events. Imagine I was building an n-way video
conference solution based on a scalable video codec, with a central point
transrating each stream based on the active speaker. Receiving codec events
in the javascript would enable me to detect rate changes and re-render the
display appropriately without requiring a full renegotiation each time.

Neil