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

On 06/09/2014 01:57 PM, Kiran Kumar Guduru wrote:
> Samsung Enterprise Portal mySingle
>
> Hi,
>
> Please find my comments inline.
>
> ------- *Original Message* -------
>
> *Sender* : Harald Alvestrand<harald@alvestrand.no>
>
> *Date* : Jun 09, 2014 20:24 (GMT+09:00)
>
> *Title* : 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:
>>
>> 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.
>
> [Kiran] In interim meeting while presenting the Error Handling slides, 
> some discussion happened on peerConnection enqueued methods like, when 
> peerConnection is closed all the methods that are enqueued to process 
> should be cancelled with 'cancelled error'.
>
> Also in case of DataChannel and DTMF, DataChannel has states to 
> identify the closed state of connection. DTMFSender has no states.
>
> So, I thought that a similar behavior seems to be good in case of DTMF 
> too.
>

The queued operation discussion was about the situation where one had a 
callback that was due to be called - we wanted it to be called in order 
to preserve the "sooner or later either success or failure is called" 
semantic.

insertDTMF doesn't have that type of callback - instead, it has an event 
handler.

WRT state, the RTCDTMFSender is really an adjunct to its associated 
MediaStreamTrack. It should have as little individual state as possible; 
if you want to know where the signal goes, follow the track attribute.