- From: <bugzilla@jessica.w3.org>
- Date: Wed, 08 Aug 2012 15:16:10 +0000
- To: public-webrtc@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18485 --- Comment #3 from Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> 2012-08-08 15:16:10 UTC --- (In reply to comment #1) > based on discussion on the list, there seems to be 3 alternate descriptions of > what sendDTMF actually does. > > I outline them below as text that can be inserted into the description. > > A) > 1) If the track argument to sendDTMF is not an audio track connected to this > PeerConnection on an outgoing SSRC where use of RFC 4733 DTMF has been > negotiated, throw a <IllegalParameter> exception. Minor note: should not an <NotSupported> exception be thrown? At least if RFC4733 has not been negotiated. Not sure <IllegalParameter> is an allowed exception, at least it is not listed here: http://www.w3.org/TR/domcore/#domexception > 2) Send the tones using RFC 4733 signalling. > > B) > 1) If the track argument to sendDTMF is not an audio track connected to this > PeerConnection, throw an <illegalParameter> exception. > 2) If sendDTMF is connected to an outgoing SSRC where use of RFC 4377 is > negotiated, send the tones using RFC 4377 and return. > 3) Insert the corresponding tones into the media stream as if they were coming > from the media source. > > C) > 1) If sendDTMF is connected to an outgoing SSRC on this PeerConnection where > use of RFC 4377 is negotiated, send the tones using RFC 4377 and return. > 2) Insert the corresponding tones into the media stream as if they were coming > from the media source. > > The difference between B) and C) is that B) insists on using the right PC to > generate tones. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.
Received on Wednesday, 8 August 2012 15:16:12 UTC