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

Re: RTCDataChannel characteristics and failures -API description -

From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
Date: Wed, 27 Aug 2014 14:31:18 +0200
Message-ID: <53FDCF96.3090507@omnitor.se>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
CC: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2014-08-27 13:39, Michael Tuexen wrote:
> On 27 Aug 2014, at 11:57, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
>
>> On 2014-08-26 23:53, Martin Thomson wrote:
>>> On 26 August 2014 14:42, Michael Tuexen
>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>> These 10 retries will then be spread over about 500 seconds, but in a really bad network the watchdog will usually abort the Association well before that, right?
>>>> As far as I understand, ICE will kick in earlier...
>>> About 470 seconds earlier.  Though that only applies to a single path.
>>> There is always a chance to create a new path between the hosts and
>>> resume the association.
>> Yes, after failure it is possible to try to reopen data channels, and that is my main point in why I propose text about failure handling in both WebRTC and rtcweb. Currently WebRTC API says that sending in reliable channels is guaranteed through retransmissions. But there is always a risk of failure.
> Correct. The peer can crash, gets disconnected, the Browser dies...
>> I have seen WebRTC developers in discussion groups being astonished that the data channels are aborted sometimes, and needing information that the channel can break and then a new open is needed to be able to continue. ( and it will sometimes be impossible to know if requested transmissions have reached the receiver. )
> Hmm. You mean WebRTC developers don't expect the peer to lose connectivity?
>> Various implementations and network environments may result in different times before the association and all channels are aborted. It will not be possible to provide exact information about that in the API spec. But it should be clear that failures can happen and what happens then.
> Again: Are you saying that developers don't think about loosing connectivity or crashing software?
> I mean, the same applies to any media channel? How is that handled?
Usually there is a description in the spec saying what happens in case 
of failure. But here it says that transmission is guaranteed.
I just want to have this specification to tell the reality.
>
> Best regards
> Michael
>> I tried to compose text proposals in this thread, and hope that they can be adjusted and included in the API spec, and when needed coordinated with text in the rtcweb channel specifications.
>>
>> Regards
>>
>> Gunnar
>>
>>
>>
>>
Received on Wednesday, 27 August 2014 12:31:47 UTC

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