google-chromewebrtcrtprtcpeerconnection

How chrome://webrtc-internal measures the round trip time?


I have been analyzing the JSON file generated using chrome://webrtc-internal, while running webrtc on 2 PCS.

I looked at Stats API to verify how webrtc-internal computes the round trip time (RTT). I found 2 ways:

  1. RTC Remote Inbound RTP Video Stream that contains roundTripTime

  2. RTC IceCandidate Pair that contains currentRoundTripTime.

Which one is accurate, why, and how is it computed?

Is RTT computed on a frame-by-frame basis?

Is it computed one way (sender --> receiver), or two ways (sender --> receiver--> sender)?

Which reports are used to measure the RTT? Is it Receiver Report RTCP or Sender Report RTCP?

What is the size of the length of GOP in the Webrtc VP8 codec?


Solution

  • RTCIceCandidatePairStats.currentRoundTripTime is computed by how long it takes for the remote peer to respond to STUN Binding Request. The WebRTC ICE Agent sends these on an interval, and each messages has a TransactionID.

    RTCRemoteInboundRtpStreamStats.currentRoundTripTime is computed by how long since the last SenderReport has been received. The sender knows when it sent, so it is able to compute how long it took to arrive.

    They are both accurate. Personally I use the ICE stats since there is less overhead. The packet doesn't have to be decrypted and routed through the RTCP subsystem. IMO ICE is also easier to deal with then RTCP.

    What is the size of the length of GOP in the Webrtc VP8 codec?. It depends on what is being encoded and the settings. Do you have a low keyframe interval? Are you encoding something with lots of changes? What are you trying to determine with this question?