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

[Randell Jesup <[e-mail]>]

On 11/14/2011 3:39 AM, Neil Stratford wrote:
> On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti <[e-mail]
> <mailto:[e-mail]>> 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.

Well, "codec" is a very strong word for RFC 4733 (though you can argue 
it's pedantically correct, and see below for why it's actually not a bad 
description in a way).

> 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)

RFC 4733 is similar to a "Partially-reliable realtime data stream with a 
limited vocabulary" - basically (typically) around 4-5 bits plus timing 
info.  However...

This is somewhat distinct from the data channels in WebRTC, though it 
might fit in there once we choose a data solution.  The problem is that 
the data solution may not match the needs of DTMF (though perhaps that 
speaks to the requirements for the data section).  Right now partial 
reliability isn't required, and would be needed OR the application would 
have to use unreliable and duplicate much of the details of RFC 4733. 
In general, we've discussed in generalities prioritization of data vs. 
media, but there's no guaranteed delivery speed for a data channel vs. a 
media channel.

However, even if you can deliver it out-of-band via a data channel, it 
wouldn't have a shared timebase (and synchronized playback) - an area 
where the 'codec' description fits better.  DTMF in terms of 4733 really 
is a media stream, just a partially-reliable one.  Ignoring 
compatibility, I would have no problem with defining it as a separate 
media stream (m= line in SDP speak) which is part of a synchronization 
group with the normal audio streams.  However, given 'normal' RTP audio 
receivers generally are already designed to handle RFC 4733, there's 
little advantage to going with a separate stream.  There might be other 
uses for such a parallel media stream, of course.

The question is how much need is there in WebRTC for a 
media-synchronized, partially-reliable data channel outside of the 
current RFC 4733 definitions?  If there is a need, we could define a use 
(or perhaps superset) of RFC 4733 that allows wider application use, in 
place of or in addition to the current RFC uses/codes.

If media synchronization isn't needed, then a data channel may do 
(depending on the data spec agreed to).

-- 
Randell Jesup
[e-mail]