Re: DTMF support

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.
>>
> ​​
>
>