- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Mon, 13 Aug 2012 14:27:49 +0000
- To: Harald Alvestrand <harald@alvestrand.no>
- CC: "<public-webrtc@w3.org>" <public-webrtc@w3.org>
got it - that make sense. Thanks. On Aug 10, 2012, at 1:12 AM, Harald Alvestrand <harald@alvestrand.no> wrote: > On 08/10/2012 12:42 AM, Cullen Jennings (fluffy) wrote: >> 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? > In my view, canSendDTMF would be true if: > a) the application supports sending of DTMF > b) the particular PeerConnection has not negotiated away 4733 support > > (Before negotiation is complete, canSendDTMF must have some value. I picked "true" because that makes a little more sense to me than "false"). >> >> 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. > I assume some responders won't support 4733. So even if all browsers support it, canSendDTMF isn't guaranteed to be true always. > >> >> >> 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 Monday, 13 August 2012 14:28:22 UTC