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

Neil Stratford <> Mon, 14 November 2011 13:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 468F921F8C92 for <>; Mon, 14 Nov 2011 05:29:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.926
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OEB25C8ucWt3 for <>; Mon, 14 Nov 2011 05:29:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5D0B811E80F5 for <>; Mon, 14 Nov 2011 05:29:20 -0800 (PST)
Received: by ywt34 with SMTP id 34so4740385ywt.31 for <>; Mon, 14 Nov 2011 05:29:16 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id xl1mr23240559igb.5.1321277356587; Mon, 14 Nov 2011 05:29:16 -0800 (PST)
Received: by with HTTP; Mon, 14 Nov 2011 05:29:16 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Mon, 14 Nov 2011 13:29:16 +0000
X-Google-Sender-Auth: 1HNgesdQhzQl53e1mdltQcYtrPw
Message-ID: <>
From: Neil Stratford <>
To: Hadriel Kaplan <>
Content-Type: multipart/alternative; boundary=14dae93409557d394c04b1b1dba7
Cc: "<>" <>
Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Nov 2011 13:29:21 -0000

On Mon, Nov 14, 2011 at 12:38 PM, Hadriel Kaplan <>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?