Re: [Bug 25977] DTMFSender should have an onerror event handler

For background - the DTMFSender, when we designed it, was thought to be 
a feature that added value in some specific places (there were use cases 
that required it), but the design should be the minimal one that 
addressed those use cases.

On 06/09/2014 11:27 AM, Kiran Kumar Guduru wrote:
> Samsung Enterprise Portal mySingle
>
> Hi,
>
> Before proposing the onError, I thought that following usecases 
> requires it.
>
> 1. To throw a state error when the RTCPeerConnection is closed while 
> the DTMF is being played. (some how I missed to add this in bugzilla)
>
why?
When the connection is closed, anyone interested in seeing if the 
connection closes will get a notification anyway.
When the connection is closed, due to the async nature of networks, you 
don't know what the last DTMF tone to reach the destination was anyway.

> 2. I though that the values other than those specified (0 to 9, a to 
> d, A to D, ',') should be treated as invalid values and should throw 
> an error. Perhaps I might have missed the discussion of ignoring 
> invalid values while playing DTMF.
>

Yes.
The typical case is playing 1-800-12-3456 or (703) 44 997 without having 
to indulge in character-stripping.

> 3. validating of duration values, ofcourse is already discarded.
>

I think clamping makes more sense. That one needs to get fixed in the 
spec, though.

> Regards,
>
> Kiran.
>
> ------- *Original Message* -------
>
> *Sender* : Harald Alvestrand<harald@alvestrand.no>
>
> *Date* : Jun 09, 2014 16:20 (GMT+09:00)
>
> *Title* : Re: [Bug 25977] DTMFSender should have an onerror event handler
>
> On 06/05/2014 11:47 AM, bugzilla@jessica.w3.org wrote:
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25977
> >
> > --- Comment #2 from Kiran ---
> > (In reply to Justin Uberti from comment #1)
> >> Shouldn't those throw an exception? Those can be easily detected
> >> synchronously.
> > I agree that duration and interToneGap ranges can be detected and 
> thrown as
> > exceptions.
> >
> > But onerror seems still required for reporting error in case of 
> inserting
> > invalid DTMF values [1], Bug: 25837.
>
> Preferring mailing list discussion rather than bugzilla discussion:
>
> After long discussion, we decided to let InsertDTMF ignore all
> unrecocnized characters:
>
> "The tones parameter is treated as a series of characters. The
> characters 0 through 9, A through D, #, and * generate the associated
> DTMF tones. The characters a to d are equivalent to A to D. The
> character ',' indicates a delay of 2 seconds before processing the next
> character in the tones parameter. Unrecognized characters are ignored."
>
> If the argument to insertDTMF is not a DOMString, TypeError will be
> thrown - this is WebIDL spec, not our spec.
>
> What were you thinking of as a possible "invalid DTMF value", given that
> it can't be a type error and it can't be an illegal character (because
> there are  none)?
>
>
> >
> > [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25837
> >
>
>