- From: Roman Shpount <roman@telurix.com>
- Date: Thu, 30 Jan 2014 15:22:09 -0500
- To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAD5OKxuJVzNuje6oF6RWVfVJPLCvEQxRuXCeBrEWT77HEcDpcQ@mail.gmail.com>
Should the interface return the values for inter tone gap and tone duration set by insertDTMF method or should it return the actual values used to transmit the tones due to rounding to the packet boundary? I would think interface should store the insertDTMF values and expanding tones to packet boundaries when actually generating tones (i.e. starting and ending tones and gaps on packet boundaries). Does changing the inter tone gap and tone duration affect the tones already queued by the interface or would only affect new DTMF tones? The way the algorithm is described right now it would affect the already queued digits which, I think, would be somewhat unexpected. It would be better to specify that tone and gap duration are queued with each digit. _____________ Roman Shpount On Thu, Jan 30, 2014 at 9:13 AM, Cullen Jennings (fluffy) <fluffy@cisco.com>wrote: > > good catch - thanks. Fixed in next version. > > On Jan 27, 2014, at 8:59 PM, Roman Shpount <roman@telurix.com> wrote: > > > Small nit: > > > > In section 6.2.1 > > > > interToneGap of type long, readonly > > The interToneGap attribute must return the current value of the > between-tone gap. This value will be the value last set via the > insertDTMF() method, or the default value of 50 ms ifinsertDTMF() was > called without specifying the interToneGap. > > > > Should be: "the default value of 70 ms ifinsertDTMF() was called without > specifying the interToneGap" > > _____________ > > Roman Shpount > > > > > > On Mon, Jan 27, 2014 at 9:24 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote: > > > > Hi > > > > A new version of the editor's draft is available. > > > > Dated version: > http://dev.w3.org/2011/webrtc/editor/archives/20140127/webrtc.html > > > > Changes include: > > > > * Make RTCPeerConnection close method be idempotent. > > * Clarified ICE server configuration could contain URI types > other than STUN and TURN. > > * Changed the DTMF timing values. > > * Allow offerToReceiveAudio/video indicate number of streams to > offer. > > * ACTION-98: Added text about clamping of maxRetransmitTime and > maxRetransmits. > > * ACTION-88: Removed nullable types from dictionaries (added > attribute default values for attributes that would be left uninitialized > without the init dictionary present. > > * InvalidMediaStreamTrackError changed to InvalidParameter. > > * Fire NetworkError when the data transport is closed with an > error. > > * Add an exception for data channel with trying to use existing > code. > > * Change maxRetransmits to be an unsigned type. > > * Clarify state changes when ICE restarts. > > * Added InvalidStateError exception for operations on a > RTCPeerConnection that is closed. > > * Major changes to Identity Proxy section. > > * (ACTION: 95) Moved IceTransports (constraint) to > RTCConfiguration dictionary. > > * (ACTION: 95) Introduced RTCOfferAnswerOptions and > RTCOfferOptions dictionaries. > > * (ACTION: 95) Removed constraints argument from addStream() > (and removed IANA Constraints section). > > * Added validation of the RTCConfiguration dictionary > argument(s). > > * Added getConfiguration() on RTCPeerConnection. > > > > Please review and provide feedback. > > > > Cullen (for the editors) > > > > > > > > > >
Received on Thursday, 30 January 2014 20:22:41 UTC