GStreamer-devel

Question about implementing WebRTC Stats

classic Classic list List threaded Threaded
♦
♦
 4 messages Options
Lin, Sherrill
Reply | Threaded
Open this post in threaded view
♦
♦
|

Question about implementing WebRTC Stats

Lin, Sherrill

Hi there,

 

Our team in Alexa Communications wants to add selected ice candidates information to WebRTC stats. We find that in gstwebrtcstats.c (https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/webrtc/gstwebrtcstats.c), RTCIceCandidateStats, RTCIceCandidatePairStats and RTCTransportStats are not constructed yet. We think these three stats are the structures needed for hosting selected ice candidate data, and we are interested in implementing them following the w3.org spec (https://www.w3.org/TR/webrtc-stats/).

 

However, we notice there’s a list of mandatory fields for implementing each stats structure: https://w3c.github.io/webrtc-pc/#mandatory-to-implement-stats. Does it mean, for Gstreamer community to accept the code changes, we will have to implement all the mandatory fields for all three stats structures as defined in that doc?

 

Thanks,

Sherrill


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Matthew Waters
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Question about implementing WebRTC Stats

Matthew Waters
Hi,

It would certainly be beneficial to Implement the mandatory stats required but it wouldn't quite be a hard rejection if they aren't implemented.  It would require a reasonable explanation as to why they aren't implemented for new structures though.

Cheers
-Matt

On 23/10/20 8:00 am, Lin, Sherrill wrote:

Hi there,

 

Our team in Alexa Communications wants to add selected ice candidates information to WebRTC stats. We find that in gstwebrtcstats.c (https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/webrtc/gstwebrtcstats.c), RTCIceCandidateStats, RTCIceCandidatePairStats and RTCTransportStats are not constructed yet. We think these three stats are the structures needed for hosting selected ice candidate data, and we are interested in implementing them following the w3.org spec (https://www.w3.org/TR/webrtc-stats/).

 

However, we notice there’s a list of mandatory fields for implementing each stats structure: https://w3c.github.io/webrtc-pc/#mandatory-to-implement-stats. Does it mean, for Gstreamer community to accept the code changes, we will have to implement all the mandatory fields for all three stats structures as defined in that doc?

 

Thanks,

Sherrill


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

OpenPGP_signature (505 bytes) Download Attachment
Lin, Sherrill
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Question about implementing WebRTC Stats

Lin, Sherrill

Hi Matthew,

 

Thanks a lot for your reply!

 

We’d like to elaborate on it a bit more. According to webrtc spec (https://w3c.github.io/webrtc-pc/#mandatory-to-implement-stats), the mandatory fields for "RTCIceCandidatePairStats" include: transportId, localCandidateId, remoteCandidateId, state, nominated, bytesSent, bytesReceived, totalRoundTripTime, currentRoundTripTime

However, we find some of the fields not easy to implement:

  1. state, nominated, totalRoundTripTime, currentRoundTripTime

These information are all related to STUN connectivity checks, which currently are not exposed in the Libnice public APIs. It would be very difficult to collect these data without modifying Libnice APIs.

  1. bytesSent, bytesReceived

These represent the total number of payload bytes sent/received on the candidate pair. We think of some potential approaches:

    1. Add buffer probes in dtlssrtpenc and dtlssrtpdemux to calculate the bytes sent/received
    2. Collect from srtpenc(https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/srtp/gstsrtpenc.c#L1205), dtlsenc(https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/dtls/gstdtlsenc.c#L519), and dtlssrtpdemux(https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/dtls/gstdtlssrtpdemux.c#L105). And we could expose an property in dtlssrtpenc and dtlssrtpdemux for the collected data.
    3. Calculate from the bytes sent/received data in RTP stream stats (https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/webrtc/gstwebrtcstats.c#L91). We would also need to gather the data for data-channel because that's not covered in RTP stream stats.

Please let us know if there's a better way to do it.

 

We'd like to get more guidance on how to implement these fields. If there's no good approach to do it yet, can we leave them out for now?

 

Thanks,

Sherrill

 

From: Matthew Waters <[hidden email]>
Date: Friday, October 23, 2020 at 2:44 AM
To: Discussion of the development of and with GStreamer <[hidden email]>, "Lin, Sherrill" <[hidden email]>
Cc: comms-media-process <[hidden email]>
Subject: RE: [EXTERNAL] Question about implementing WebRTC Stats

 

Hi,

It would certainly be beneficial to Implement the mandatory stats required but it wouldn't quite be a hard rejection if they aren't implemented.  It would require a reasonable explanation as to why they aren't implemented for new structures though.

Cheers
-Matt

On 23/10/20 8:00 am, Lin, Sherrill wrote:

Hi there,

 

Our team in Alexa Communications wants to add selected ice candidates information to WebRTC stats. We find that in gstwebrtcstats.c (https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/webrtc/gstwebrtcstats.c), RTCIceCandidateStats, RTCIceCandidatePairStats and RTCTransportStats are not constructed yet. We think these three stats are the structures needed for hosting selected ice candidate data, and we are interested in implementing them following the w3.org spec (https://www.w3.org/TR/webrtc-stats/).

 

However, we notice there’s a list of mandatory fields for implementing each stats structure: https://w3c.github.io/webrtc-pc/#mandatory-to-implement-stats. Does it mean, for Gstreamer community to accept the code changes, we will have to implement all the mandatory fields for all three stats structures as defined in that doc?

 

Thanks,

Sherrill



_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel




_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Olivier Crête-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Question about implementing WebRTC Stats

Olivier Crête-3
Hi,

Answering with my libnice maintainer hat.

On Tue, 2020-10-27 at 19:31 +0000, Lin, Sherrill wrote:

Hi Matthew,

 

Thanks a lot for your reply!

 

We’d like to elaborate on it a bit more. According to webrtc spec (https://w3c.github.io/webrtc-pc/#mandatory-to-implement-stats), the mandatory fields for "RTCIceCandidatePairStats" include: transportId, localCandidateId, remoteCandidateId, state, nominated, bytesSent, bytesReceived, totalRoundTripTime, currentRoundTripTime

However, we find some of the fields not easy to implement:

  1. state, nominated, totalRoundTripTime, currentRoundTripTime

These information are all related to STUN connectivity checks, which currently are not exposed in the Libnice public APIs. It would be very difficult to collect these data without modifying Libnice APIs.


Libnice currently the state and nominated-ness of each pair in an internal data structure. I think it would be relatively simple to just add a function to retrieve a copy of those.

Libnice doesn't currently measures the RTT, but we could relatively easily store the time when a STUN request is sent and do the substraction when a reply is received to get this. And we could expose it in the same API.

  1. bytesSent, bytesReceived

These represent the total number of payload bytes sent/received on the candidate pair. We think of some potential approaches:

    1. Add buffer probes in dtlssrtpenc and dtlssrtpdemux to calculate the bytes sent/received
    2. Collect from srtpenc(https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/srtp/gstsrtpenc.c#L1205), dtlsenc(https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/dtls/gstdtlsenc.c#L519), and dtlssrtpdemux(https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/dtls/gstdtlssrtpdemux.c#L105). And we could expose an property in dtlssrtpenc and dtlssrtpdemux for the collected data.
    3. Calculate from the bytes sent/received data in RTP stream stats (https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/webrtc/gstwebrtcstats.c#L91). We would also need to gather the data for data-channel because that's not covered in RTP stream stats.

Please let us know if there's a better way to do it.


I wonder if the best approach wouldn't be to calculate these in libnice and expose them from there directly.

Doing this at the GStreamer level wouldn't give the accurate result per candidate pair.

Olivier

 

We'd like to get more guidance on how to implement these fields. If there's no good approach to do it yet, can we leave them out for now?

 

Thanks,

Sherrill

 

From: Matthew Waters <[hidden email]>
Date: Friday, October 23, 2020 at 2:44 AM
To: Discussion of the development of and with GStreamer <[hidden email]>, "Lin, Sherrill" <[hidden email]>
Cc: comms-media-process <[hidden email]>
Subject: RE: [EXTERNAL] Question about implementing WebRTC Stats

 

Hi,

It would certainly be beneficial to Implement the mandatory stats required but it wouldn't quite be a hard rejection if they aren't implemented.  It would require a reasonable explanation as to why they aren't implemented for new structures though.

Cheers
-Matt

On 23/10/20 8:00 am, Lin, Sherrill wrote:

Hi there,

 

Our team in Alexa Communications wants to add selected ice candidates information to WebRTC stats. We find that in gstwebrtcstats.c (https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/webrtc/gstwebrtcstats.c), RTCIceCandidateStats, RTCIceCandidatePairStats and RTCTransportStats are not constructed yet. We think these three stats are the structures needed for hosting selected ice candidate data, and we are interested in implementing them following the w3.org spec (https://www.w3.org/TR/webrtc-stats/).

 

However, we notice there’s a list of mandatory fields for implementing each stats structure: https://w3c.github.io/webrtc-pc/#mandatory-to-implement-stats. Does it mean, for Gstreamer community to accept the code changes, we will have to implement all the mandatory fields for all three stats structures as defined in that doc?

 

Thanks,

Sherrill



_______________________________________________
gstreamer-devel mailing list
[hidden email] 
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
 



_______________________________________________
gstreamer-devel mailing list
[hidden email]

https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

--
Olivier Crête


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Free forum by Nabble Edit this page