Re: Re: A proposal for returning STUN/TURN server errors to applications

I would be OK with the concept of a general onError callback as long as it
can emit different objects, e.g. a CandidateError that has URI and
code/reason parameters.


On Sun, May 18, 2014 at 9:32 PM, Kiran Kumar Guduru <
kiran.guduru@samsung.com> wrote:

>
>
> Hi,
>
> I proposed an onError event for RTCPeerConnection to fire
> RTCPeerConnectionErrorEvent.
>
> We can use this single error event for almost all kinds of errors that may
> arise on RTCPeerConnection, with different error names.
>
> like
>
> NetworkError
>
> IceCandidateError
>
> and some more that might be discussed, some time down the line in the
> group.
>
> Propably you might see that in Error Handling slides to be discussed on
> day-2.
>
>
>
>
>
> ------- *Original Message* -------
>
> *Sender* : Roman Shpount<roman@telurix.com>
>
> *Date* : May 19, 2014 12:59 (GMT+09:00)
>
> *Title* : Re: A proposal for returning STUN/TURN server errors to
> applications
>
>
>
> I would also suggest to add |reason| to onicecandidateerror.
> On May 18, 2014 2:43 PM, "Justin Uberti" <juberti@google.com> wrote:
>
>> Currently, there is no way to know if you failed to get STUN/TURN
>> candidates from the servers specified in RTCConfiguration, except by
>> working backwards from the generated candidates to see if they match what
>> you expect, which is inexact at best.
>>
>> This includes cases where the server is unreachable (due to server
>> problems or a bad URI), as well as authentication failures.
>>
>> To improve this situation, I suggest the following changes:
>> - in RTCPeerConnectionIceEvent, add the URI for the RTCIceServer used to
>> generate the candidate as a new |uri| parameter. For host candidates, this
>> parameter will be null. This will allow apps to know if they were able to
>> successfully obtain candidates from a specific STUN/TURN server.
>> - add a new onicecandidateerror event, which emits an event for every URI
>> that did not generate the expected candidates (e.g. srflx for a STUN
>> server, relay for a TURN server). The onicecandidateerror event has two
>> fields, |uri|, and |code|, where code is either the error from the server,
>> or some 6xx error code if the connection failed.
>>
>> In some cases, it could be possible to get both a success and error event
>> from the same server, e.g. if a STUN address was allocated but a TURN
>> request failed.
>>
>
>
>
>
>
>
>