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

Re: RTCDataChannel characteristics and failures -API description - comment to the 20140127 version

From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
Date: Wed, 05 Feb 2014 07:16:34 +0100
Message-ID: <52F1D742.1000702@omnitor.se>
To: Martin Thomson <martin.thomson@gmail.com>
CC: Web-rtc <public-webrtc@w3.org>
On 2014-02-04 22:52, Martin Thomson wrote:
> On 4 February 2014 11:40, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
>> If an application opens a data channel and requests the unreliable type with
>> maximum 7 retries.
>> And it turns out that the reliable type by default makes maximum 5 retries.
> All I was looking for was that default == maximum.
> What we do if someone asks for more than the maximum is a separate
> question.  I'm OK with clamping down to the supported maximum if more
> are requested, but given recent ...erm ...discussions, that might not
> be an uncontroversial position.
The more important points are not solved yet in my proposal.
That is to get a full description of what happens in the API in failure 
situations on the sending side and on the receiving side.

In some situations there are callback events, in others not.
And some parameter should be provided in the callback about the reason.

This is as far as I commented on this part of the topic:
4. More general information about failures should be provided. Proposal 
to add one more sentence in the same paragraph:

"The status of the PeerDataConnection is also monitored through 
heartbeats, and lack of a number of heartbeats from the peer, or closing 
of other channels in the PeerDataConnection or other failure indications 
will cause the connection to be teared down. The status of the 
transmission at the time of failure can be interrogated in the transmit 
buffer as described by the BufferedAmount attribute."

5. Details in the API description.
The indications about the functionality described above and suggested to 
the paragraph in 5.2, then needs to be detailed in the API descriptions 
elsewhere in chapter 5,
mainly in the parameters of the
in 5.3

I can start proposing details, but wanted to see if there was agreement 
to do this first.
Received on Wednesday, 5 February 2014 06:17:07 UTC

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