- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jun 2022 11:33:34 +0000
- To: public-webrtc-logs@w3.org
Regarding this issue... ### Topic A: When should RTP stream stats objects be created? Arguments in favor of adding sender/receiver/transceiver: - It matches the RTP Media API perfectly. - While not implemented, they would be trivial to implement. Arguments in favor of creating RTP stream stats as soon as the senders and receivers have been negotiated (not delaying this until you get the first packet): - It's what most implementations do already and possibly what people have come to expect. - You are already able to identify the RTP stream using mid (and rid in the case of simulcast). - You are already able to tell whether or not a packet has been sent or received by looking at the packet counters. - Less bloated stats reports: no need for sender/receiver/transceiver stats objects. - Not having to know the SSRC in order to create these objects is liberating considering the SDP may or may not have signalled the SSRCs (we still put SSRCs in the SDP for backwards compatibility reasons but one could imagine we stop doing that, it would be nice not to have RTP stream stats be conditioned on the SDP implementation status). ### Topic B: When should RTP stream stats objects be destroyed? The spec says they should never be deleted. Chromium never implemented this, what about Firefox? Arguments in favor: - Not deleting them allows inspecting RTP metrics at the end of the call. Arguments against: - AFAIK never implemented and "at risk". - Arguably not that useful, in practice most apps poll getStats ever 1-10 seconds. - This is a memory leak. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/643#issuecomment-1164297510 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 23 June 2022 11:33:36 UTC