W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2014

Re: Proposal: Fire a toneDiscarded event while discarding the invalid DTMF values.

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Fri, 13 Jun 2014 14:27:27 +0200
Message-ID: <539AEE2F.1030909@ericsson.com>
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Harald Alvestrand <harald@alvestrand.no>, Justin Uberti <juberti@google.com>
CC: Kiran Kumar Guduru <kiran.guduru@samsung.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2014-06-13 14:11, Makaraju, Maridi Raju (Raju) wrote:
>> On 13/06/14 10:00, Harald Alvestrand wrote:
>>> On 06/13/2014 07:47 AM, Justin Uberti wrote:
>>>> Passing in a bad string of tones seems like a programming error, and
>>>> we should throw an exception immediately.
>> +1
>>> are you suggesting that all apps should be required to know how to strip
>>> +1 (707) 344-4489 to 17073444489, or are you suggesting a more complex
>> IMO it should be required to know how to strip.
> [Raju] IMO, insertDTMF() API ignoring standard well-known phone
> numbers format separators (for readability) is probably better. These
> include "+-.()". This behavior makes webrtc consistent existing
> systems where these are mostly ignored. This also makes it consistent
> with webrtc handling of "," even though it is not a DTMF symbol.
> These separators are documented in
> http://www.ietf.org/rfc/rfc3601.txt . This RFC uses 'p' for pause
> instead of ','. I think ',' is widely accepted and is ok for webrtc
> use.
> I also agree with the comment that every app writing code to parse
> and remove these very common separators is un-necessary and may give
> bad taste for the API.

So if the general rule would be to throw on unrecognized characters. But 
we add common number separators, like "+-.()", to our list of 
recognized, but specially handled characters (to be ignored in this 
case). And then we don't notify the script when we simply skip over an 
ignored character.

That would work for me.

Received on Friday, 13 June 2014 12:27:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:59 UTC