DTMF Support

[aboba]

From: Justin Uberti juberti@google.com
To: public-orca@w3.org
Date: Thu, 6 Feb 2014 11:21:21 -0800
URL: http://lists.w3.org/Archives/Public/public-orca/2014Feb/0014.html

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.

[aboba]

[Peter Thatcher]

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

[steely-glint]

On 6 Feb 2014, at 21:14, aboba notifications@github.com wrote:

From: Justin Uberti juberti@google.com
To: public-orca@w3.org
Date: Thu, 6 Feb 2014 11:21:21 -0800
URL: http://lists.w3.org/Archives/Public/public-orca/2014Feb/0014.html

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.

Just because it needs saying.....

We don't actually have to add DTMF here. There are other ways to do it that
already work. Phono sends DTMF over the signalling channel (think SIP INFO).
If you want it to go down the media channel, then you can use webAudio to create and
mix in the requisite DTMF tones. (If you are building a phonebox on the web, lets do it
properly retro!). Of course you'd probably want to use ulaw as the codec too!

T.

[martinthomson]

I'm not sure that I agree @steely-glint. There's this uncomfortable middle ground where devices don't pull DTMF tones off the audio stream because they are RTP devices that support the DTMF "codec". What you propose would leave them in the rough.

[steely-glint]

On 7 Feb 2014, at 17:23, Martin Thomson notifications@github.com wrote:

I'm not sure that I agree @steely-glint. There's this uncomfortable middle ground where devices don't pull DTMF tones off the audio stream because they are RTP devices that support the DTMF "codec". What you propose would leave them in the rough.

You really have one of those that can't do SIP info or inband tones but can do DTLS and full ice ?

T.

[rshpount]

On Fri, Feb 7, 2014 at 12:34 PM, steely-glint notifications@github.comwrote:

On 7 Feb 2014, at 17:23, Martin Thomson notifications@github.com wrote:

I'm not sure that I agree @steely-glint. There's this uncomfortable
middle ground where devices don't pull DTMF tones off the audio stream
because they are RTP devices that support the DTMF "codec". What you
propose would leave them in the rough.

You really have one of those that can't do SIP info or inband tones but
can do DTLS and full ice ?

First of all SIP INFO DTMF has a real problems synchronizing with media.
Things like record your name and press the pound key quite commonly get
messed up.

Second, in-the-audio-stream DTMF has an issue in the presence of packet
loss. Quite often one tone becomes two.

Finally, ORTC is supposed to allow implementation of current WebRTC spec on
top of it. Unless we support similar DTMF tone functionality this would be
impossible.

Bottom line, DTMF is a legacy feature, but while we need to interact with
old telephony services, we are stuck with it.

---

Roman Shpount

[martinthomson]

I don't know, this is an old argument that I'm not sure I care for. In the grand scheme of things, I consider intermediation costs to be progressively higher for ICE, then DTLS, then codec stuff. And for some reason, there's a big gap in my mind between the last two. For instance, the former two don't add extra delay. But there's probably a good dollop of prejudice influencing that.

[steely-glint]

On 7 Feb 2014, at 17:38, rshpount notifications@github.com wrote:

Finally, ORTC is supposed to allow implementation of current WebRTC spec on
top of it. Unless we support similar DTMF tone functionality this would be
impossible.

I understand and respect that POV. However it may turn out to be an excessive
burden. The current webRTC spec is a moving (and ever expanding) target.
Only today I saw t38 buried in a rtcweb draft.

Tim.

[aboba]

Please review the fixes relating to this issue in the latest ORTC Editor's draft:
http://ortc.org/wp-content/uploads/2014/02/ortc.html

If there are any remaining concerns, please post these to the public-orca@w3.org mailing list.