Re: DTMF support

Looks good.
On Feb 6, 2014 2:52 PM, "Justin Uberti" <juberti@google.com> wrote:

> I see; so instead of 'get DtmfSender from RtpSender', it becomes 'attach
> DtmfSender to RtpSender'. That does seem more consistent.
>
> Also agree on RTCDtmfSender.
>
>
> On Thu, Feb 6, 2014 at 1:39 PM, Peter Thatcher <pthatcher@google.com>wrote:
>
>> ​I like this idea, and I like the idea of changing the reference to track
>> to being a reference to the RtpSender.
>>
>> But would
>>  it make sense t
>> ​o pass ​the RtpSender into a constructor of the DtmfSender?
>>
>>
>> [Constructor(RTCRtpSender)]
>> interface RTCDTMFSender {
>>     readonly    attribute boolean          canInsertDTMF;
>>     void insertDTMF (DOMString tones, optional long duration,
>>                      optional long interToneGap);
>>     readonly    attribute
>> ​RTCRtpSender      sender​
>> ;
>>                 attribute EventHandler     ontonechange;
>>     readonly    attribute DOMString        toneBuffer;
>>     readonly    attribute long             duration;
>>     readonly    attribute long             interToneGap;
>> };
>>
>> ​I think that's more consistent with the rest of our objects.​
>>
>>
>> And can we call it DtmfSender?  We have RtpSender and IceTransport and
>> SctpTransport, not RTPSender, ICETransport, and SCTPTransport.  DTMFSender
>> seems out of place, and "RTCDTMF" just looks crazy.
>>
>>
>>
>> On Thu, Feb 6, 2014 at 11:21 AM, Justin Uberti <juberti@google.com>wrote:
>>
>>> One thing absent from the current API is support for DTMF. Yes, it's a
>>> relic from an earlier age, but unfortunately it's not something we can
>>> ignore.
>>>
>>> Fortunately, the 1.0 spec did a nice job factoring DTMF functionality
>>> out into the RTCDTMFSender <http://www.w3.org/TR/webrtc/#rtcdtmfsender>object. After calling PeerConnection.createDTMFSender(track), a
>>> RTCDTMFSender is created and attached to |track|. This object then allows
>>> DTMF to be injected into the audio stream for the specified track.
>>> Visually, it looks like this (in 1.0):
>>>
>>>
>>>                           |---------------------------|
>>>                           |       PeerConnection      |
>>> MediaStreamTrack --> |Doohickey |                     |
>>>                           |  ^                        |
>>>                           |  |                        |
>>>                      |RTCDTMFSender|                  |
>>>                            |                           |
>>>                           |---------------------------|
>>>
>>> So, we should be able to reuse this whole object in ORTC. All we need to
>>> do is find a way to create a RTCDTMFSender for a given track, which we can
>>> do just by adding a getDTMFSender() API to RTCRtpSender, and we end up with
>>> a model like:
>>>
>>>
>>> MediaStreamTrack --> RTCRtpSender ---> Transports
>>>                           ^
>>>                           |
>>>                      RTCDTMFSender
>>>
>>> The API delta then becomes:
>>>
>>> partial interface RTCRtpSender {
>>>     // gets/creates the RTCDTMFSender object for the current RTCRtpSender
>>>     RTCDTMFSender getDTMFSender();
>>> }
>>>
>>> and this taken from 1.0:
>>>
>>> [NoInterfaceObject]
>>> interface RTCDTMFSender {
>>>     readonly    attribute boolean          canInsertDTMF;
>>>     void insertDTMF (DOMString tones, optional long duration,
>>>                      optional long interToneGap);
>>>     readonly    attribute MediaStreamTrack track;
>>>                 attribute EventHandler     ontonechange;
>>>     readonly    attribute DOMString        toneBuffer;
>>>     readonly    attribute long             duration;
>>>     readonly    attribute long             interToneGap;
>>> };
>>>
>>> The only other edit we might want to make is to replace the |track|
>>> reference with a reference to the RTCRtpSender the RTCDTMFSender is
>>> attached to.
>>>
>> ​​
>>
>>
>