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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 09 Jun 2014 14:04:54 +0200
Message-ID: <5395A2E6.1060203@alvestrand.no>
To: kiran.guduru@samsung.com, "public-webrtc@w3.org" <public-webrtc@w3.org>
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" 

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

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.
Received on Monday, 9 June 2014 12:05:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:41 UTC