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

[Neil Stratford <[e-mail]>]

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