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

Neil Stratford <neils@belltower.co.uk> Mon, 14 November 2011 13:29 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 468F921F8C92 for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 05:29:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.926
X-Spam-Level:
X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, 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 OEB25C8ucWt3 for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 05:29:20 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B811E80F5 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 05:29:20 -0800 (PST)
Received: by ywt34 with SMTP id 34so4740385ywt.31 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 05:29:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.160.161 with SMTP id xl1mr23240559igb.5.1321277356587; Mon, 14 Nov 2011 05:29:16 -0800 (PST)
Sender: neils@vipadia.com
Received: by 10.231.207.10 with HTTP; Mon, 14 Nov 2011 05:29:16 -0800 (PST)
In-Reply-To: <C5BCCDCC-75C5-4D03-80A8-20D5A0259E79@acmepacket.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> <CABRok6nYi4tg1wJt=0xbw6tkp8JDT4FEpxgW=Uhovx=j+w3=bA@mail.gmail.com> <CAOJ7v-3ju51yg8oP2czjESLcw3b_5ZuygfL-QreZ3aLvRW11AA@mail.gmail.com> <CABRok6nfFC8tc2uZG5AOxspPuOUA4JGvsVNHWPrC0xV8ay2KAQ@mail.gmail.com> <CAOJ7v-13_i-1nHR4==VXbdD=nRVzHDatq_bOo3-s-7Rj_yAWHQ@mail.gmail.com> <CABRok6mq5W-BSNJuZvDrWKhTeedkJC9DMegNUSxHqMDSWmssBw@mail.gmail.com> <C5BCCDCC-75C5-4D03-80A8-20D5A0259E79@acmepacket.com>
Date: Mon, 14 Nov 2011 13:29:16 +0000
X-Google-Sender-Auth: 1HNgesdQhzQl53e1mdltQcYtrPw
Message-ID: <CABRok6nkTFcuYDzs1HWzekOkd0SZZjuFuGGbbh0nDJEH8VAGfQ@mail.gmail.com>
From: Neil Stratford <neils@belltower.co.uk>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: multipart/alternative; boundary=14dae93409557d394c04b1b1dba7
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 13:29:21 -0000

On Mon, Nov 14, 2011 at 12:38 PM, Hadriel Kaplan <HKaplan@acmepacket.com>wrote;wrote:

>
> On Nov 14, 2011, at 6:48 AM, Neil Stratford wrote:
>
> > 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.
>
> If you create your own media server, you can do whatever you want - you
> don't need the IETF for anything.  I mean you can open a SCTP/DTLS/UDP
> data-channel and send whatever you want over it; or you can open a
> websocket to it and send whatever you want over it, etc.  Why would you
> even use "DTMF" for that - i.e., why would you constrain yourself to only a
> few digits/characters?
>

I'd constrain myself because that's all I can forward on over the PSTN to
the remote IVR. If the 'IVR' was implemented using the WebRTC media server
I'm sure the control channel wouldn't restrict itself to a few digits.


> The only reason to have "DTMF" as true "DTMF" a la rfc4733 is to be able
> to use media-servers created from other vendors/third-parties, possibly not
> even managed/owned by the same domain as WebRTC is running in.  But for
> that to work, it needs to be based on a standard.  The only two IETF
> standards for that today are KPML and RFC4733.  And if we want it to be
> based on a standard most media-servers actually implement, that would be
> RFC4733.


RFC4733 is fine, I was just arguing that if you have a better transport for
DTMF available than RTP it seems a shame not to use it, especially given we
don't have the usual timing/sync problem as the DTMF can only be generated
via an API. I guess in the Javascript application we'll have to figure out
if the remote peer is happy to receive DTMF over DataStream via the
signalling channel, and then implement a different sendDigit() function. I
may be alone in having had bad experiences with DTMF RTP reliability.

If we support outbound DTMF, should we support inbound DTMF as well, so I
can write an IVR in a WebRTC browser? (eg. think calling to control a
webcam that is streaming from a browser) Should it fire events to the
javascript on a DTMF digit being received?  What about continuation events,
one event for the start and repeats until it finishes? What should play the
local DTMF tone - should it be implicit in the API, or do we need a tone
generator that can be invoked?

Neil