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.
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>