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

Re: DTMF support

From: Justin Uberti <juberti@google.com>
Date: Thu, 6 Feb 2014 14:51:29 -0800
Message-ID: <CAOJ7v-2Vvnka_4KCz8X8Qgs6hONtMbdj544H7PH9BGF=2t4YgQ@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Cc: "public-orca@w3.org" <public-orca@w3.org>
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.
>>
> ​​
>
>
Received on Thursday, 6 February 2014 22:52:17 UTC

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