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

On 06/09/2014 02:24 PM, Kiran Kumar Guduru wrote:
> Samsung Enterprise Portal mySingle
>
> ------- *Original Message* -------
>
> *Sender* : Harald Alvestrand<harald@alvestrand.no>
>
> *Date* : Jun 09, 2014 21:04 (GMT+09:00)
>
> *Title* : Re: [Bug 25977] DTMFSender should have an onerror event handler
>
> On 06/09/2014 01:57 PM, Kiran Kumar Guduru wrote:
>>
>> 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.
>
> [Kiran] Agreed
>
> 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.
>
> [Kiran] I did not find any relation between peerConnection/DTMFSender 
> state and MediaStreamTrack state directly.  Do you mean that 
> MediaStreamTrack of a DTMFSender should be changed to ended state in 
> this case?
>

No. thinking about it some more, I don't think it makes sense for the 
MST to be ended either.
It just complicates the interface to attempt to observe the state of the 
connection through this interface.

I don't think RTCDTMFSender should have state, apart from its tone 
buffer. If you want to know if the PC has been terminated, the app 
should be looking at the PC, not the RTCDTMFSender.