- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Thu, 9 Aug 2012 22:42:47 +0000
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
I suspect I like this change but I don't really understand what the proposal is. Could a bit more be provided. What does canSendDTMF do? My view is the easiest thing to do is negotiate 4733 DTMF on all audio streams. I don't care much about if browsers can receive DTMF but it seems very useful. If we do have some sort of play out of generated tones, that sounds hard but whatever we do we have to make sure that the echo can not end up causing double presses. On Aug 3, 2012, at 6:01 PM, Harald Alvestrand <harald@alvestrand.no> wrote: > (wearing my co-Chair hat) > I've discussed this with several people at the IETF meeting. Unless someone raises an objection, the chairs will instruct the editors to make this change. > > On 08/03/2012 04:57 PM, bugzilla@jessica.w3.org wrote: >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18485 >> >> Summary: Change DTMF API to be on PeerConnection >> Product: WebRTC Working Group >> Version: unspecified >> Platform: PC >> OS/Version: Linux >> Status: NEW >> Severity: normal >> Priority: P2 >> Component: WebRTC API >> AssignedTo: public-webrtc@w3.org >> ReportedBy: harald@alvestrand.no >> CC: public-webrtc@w3.org >> >> >> Implementing the proposed DTMF API has turned out to be surprisingly complex >> compared to the importance of the feature; the typing requirements for >> MediaStream seem to be heavily complicated by it. >> >> Tommy Widenflycht has suggested instead that we define calls to make available: >> >> pc.canSendDTMF(MediaStreamTrack) >> pc.sendDTMF(MediaStreamTrack, tones, duration) >> >> This has no impact on the definition of MediaStream and allows implementation >> of sendDTMF without touching anything but PeerConnection. >> > >
Received on Thursday, 9 August 2012 22:43:16 UTC