- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Oct 2018 16:10:07 +0000
- To: public-webrtc-logs@w3.org
> > That's a bug. > > AFAIK it's not a bug, since bufferedAmount don't include the sctp buffer. It is definitely a bug. See the [corresponding spec section](https://w3c.github.io/webrtc-pc/#dom-rtcdatachannel-bufferedamount). The only reason why all implementations are affected by this is because they all use usrsctp which currently does not expose that information. > Since, we are on the topic of this, what other SCTP stats would applications want to use? also are there any other SCTP metrics that would be interesting for the app I'm not seeing further items that should be in the stats (there are a couple that could be added to `RTCSctpTransport` at some point, such as MTU, partial delivery point, RT max, RTO initial/min/max, heartbeat interval, ...). Arguably, some of these *could* also be in the stats but I'm not entirely convinced about that so far. > also interesting but more futuristic, for us at least: maximum size for data payload before packet will be split to 2 (mtu - all the headers calculation) I believe that should not be in the stats but rather on the `RTCSctpTransport`. Interesting candidates are https://tools.ietf.org/html/rfc6458#section-8.2.1 `sstat_fragmentation_point` and https://tools.ietf.org/html/rfc6458#section-8.2.2 `spinfo_mtu` (I'm not sure what's the difference between those two and would have to ping my fellow SCTP expert for that). -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/377#issuecomment-432312840 using your GitHub account
Received on Tuesday, 23 October 2018 16:10:09 UTC