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

[Neil Stratford <[e-mail]>]

On Mon, Nov 14, 2011 at 3:34 PM, Randell Jesup <[e-mail]>wrote:

> On 11/14/2011 4:53 AM, Iñaki Baz Castillo wrote:
>
>> But DTMF was the topic of the email.
>>>
>>
>> RTP/SRTP is unreliable so sending like-reliable information (DTMF's)
>> over an unreliable stream is, for sure, not the best design. In WebRTC
>> such reliable info could be sent over signaling or over the
>> data-channel (both of them reliable). Why to choose the worst option?
>> reply: to interoperate with existing VoIP protocols.
>>
>
> Note my other email I just sent - DTMF has a property not shared by the
> data streams - media synchronization.  I won't repeat all the arguments
> here, but there actually is a reason for delivering it in a media channel,
> totally regardless of legacy.  For a greenfield design, one *might*
> implement it as a separate media stream (m= line), but even there I'm not
> sure I would mandate it be separated.


How can we achieve the media synchronization in WebRTC? In a traditional
RTC endpoint the DTMF comes from the same source as the media, in many
cases it's actually taken from the media itself. However in WebRTC the only
way to trigger a DTMF event is through an asynchronous Javascript function
call, which is not synchonized to the media. Do we assume that the function
call happens 'at about the right time' and take that as the current
timestamp to use?