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

I think we won't be happy with that. I would suggest we have separate error
objects that all have a .name property, and the application can do
different things depending on .name.


On Mon, May 19, 2014 at 7:10 AM, Kiran Kumar Guduru <
kiran.guduru@samsung.com> wrote:

>  Then we can add one more attribute (whose name yet to be decided), which
> should be useful for IceCandidateError to specify the URI as well as for
> other errors that may be recognized in future. Behavior of this attribute
> will be decided based on the name.
>
>
>
> Thanks,
>
> Kiran.
>
>
>
> ------- *Original Message* -------
>
> *Sender* : Justin Uberti<juberti@google.com>
>
> *Date* : May 19, 2014 23:02 (GMT+09:00)
>
> *Title* : Re: Re: Re: A proposal for returning STUN/TURN server errors to
> applications
>
>
> I don't think name and message are sufficient. Name would be used to
> indicate a gathering error, and message is implementation-dependent,
> meaning it would not be possible to programmatically extract URI and code.
>
>
> On Mon, May 19, 2014 at 6:53 AM, Kiran Kumar Guduru <
> kiran.guduru@samsung.com> wrote:
>
>>  For now, the initial proposal has name and message.
>>
>> Name and message attributes will give the required information for most
>> of the cases.
>>
>> (Since URI is specific to IceCandidates, we may add explanation of URI in
>> message).
>>
>> For any error, if it becomes mandatory to add some more extra
>> information, then we can extend this event.
>>
>>
>>
>>
>>
>> ------- *Original Message* -------
>>
>> *Sender* : Justin Uberti<juberti@google.com>
>>
>> *Date* : May 19, 2014 22:26 (GMT+09:00)
>>
>> *Title* : 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.
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>