W3C home > Mailing lists > Public > public-orca@w3.org > February 2014

Re: DTMF support

From: Peter Thatcher <pthatcher@google.com>
Date: Thu, 6 Feb 2014 13:39:27 -0800
Message-ID: <CAJrXDUE6eaRK5Dx3jYVeFG8io09ox-5JtBkcm=8rg3Jdu-Ld=Q@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: "public-orca@w3.org" <public-orca@w3.org>
​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.
>
​​
Received on Thursday, 6 February 2014 21:47:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:24 UTC