Need consistent name for RTT estimate on RTCRTPStreamStats and on ICECandidatePair about webrtc-stats HOT 16 CLOSED

If nobody's implemented the candidate pair RTT variables (sumRtt and currentRtt), I'd like to rename those to sumRoundTripTime and currentRoundTripTime.

from webrtc-stats.

@alvestrand we do have Rtt in OutboundRtpStats, it is called roundTripTime and should be calculated based on data in the RTCP RR.

dictionary RTCOutboundRTPStreamStats : RTCRTPStreamStats {
    unsigned long      packetsSent;
    unsigned long long bytesSent;
    double             targetBitrate;
    double             roundTripTime;
};

roundTripTime of type double
Estimated round trip time for this SSRC based on the RTCP timestamps in the RTCP Receiver Report (RR) and measured in seconds. Calculated as defined in section 6.4.1. of [RFC3550].

from webrtc-stats.

Oops. Sorry. Closing as "missed it".

from webrtc-stats.

which means (which caused this issue and confused me as well) that we now have one roundTripTime (on stream stats) and two "rtt" in https://w3c.github.io/webrtc-stats/#dom-rtcicecandidatepairstats-currentrtt

For the sake of consistency either both should be abbreviated or none. I have no opinion which one ;-)

from webrtc-stats.

we could change it to RTT. @alvestrand, @jan-ivar -- what do you think?

from webrtc-stats.

Reopening and renaming issue.
Stylistically, I prefer the longer name. But I'd prefer to go with whatever's implemented first. @ShijunS @jan-ivar?

from webrtc-stats.

@vr000m We implement mozRtt in RTCInboundRTPStreamStats, since rtcp info is in the opposite dictionary . E.g.

{ "id": "outbound_rtcp_video_1",
 "timestamp": 1477343155549.51,
 "type": "inboundrtp", "isRemote": true,
 "mediaType": "video",
 "remoteId": "outbound_rtp_video_1",
 "ssrc": "892087744",
 "bytesReceived": 99076,
 "jitter": 0.289,
 "mozRtt": 1,
 "packetsLost": 0,
 "packetsReceived": 124 
}

How come you have it on RTCOutboundRTPStreamStats ?

You can get a dump in FF from https://jsfiddle.net/jib1/moz71L7h/

@alvestrand I have no strong preference on naming.

from webrtc-stats.

@jan-ivar my interpretation of RTT is that you compute it on the sender by comparing the time you get an RTCP RR for a given RTP timestamp with the time you sent that RTP timestamp (- the delta between packet reception and RTCP emission, which is part of the RR). This is a computation that can only be done at the sender.

I'm sure @vr000m will now jump out and correct my misapprehension....

from webrtc-stats.

@alvestrand is correct. The RTT is calculated at the sender-side. By using the info in the RTCP RR. The calculation is explained in detail in RFC3550.

RTT is calculated by subtracting the the sum of the two timestamps (LSR and DLSR) in RTCP RR from the reception time of the RTCP RR.

from webrtc-stats.

To echo what @vr000m said, Edge has "roundTripTime" in RTCOutboundRTPStreamStats on the sender side. Naming wise, I'd prefer the longer name.

from webrtc-stats.

I suppose no real change needed. I'll abbreviate the roundtriptime to RTT in the definition for the RTP metric, so that word search should find it.

from webrtc-stats.

@vr000m , @alvestrand This is all sender-side. Isn't the important distinction instead that (calculations off) data from RTCP RR, normally go in the "remote" dictionary?

We can't have an RTT calculation without an RTCP RR, so it seemed logical to put it with the RTCP RR data, when we consider that RTCP RR's happen less frequently than local-only sampling:

E.g. from a local-loop test:

// This one is calculated from RTCP RR data (received sender-side):
{ "id": "outbound_rtcp_video_1",
 "timestamp": 1477409522010.406, // Time is T + 0
 "type": "inboundrtp",
 "isRemote": true,
 "mediaType": "video",
 "remoteId": "outbound_rtp_video_1",
 "ssrc": "2107138979", "bytesReceived": 176175,
 "jitter": 0.479, "mozRtt": 1,
 "packetsLost": 0,
 "packetsReceived": 243
},
// This one is only about data going out, or about to go out (sender-side):
{ "id": "outbound_rtp_video_1",
 "timestamp": 1477409522019.865, // Time is T + 9.46 (newer!)
 "type": "outboundrtp",
 "bitrateMean": 309833,
 "bitrateStdDev": 79133.13772055294,
 "framerateMean": 30.4,
 "framerateStdDev": 0.547722557505166,
 "isRemote": false,
 "mediaType": "video",
 "remoteId": "outbound_rtcp_video_1",
 "ssrc": "2107138979",
 "bytesSent": 194721,
 "droppedFrames": 0,
 "packetsSent": 261
}

As you can see here, the RTCP data is older, because they only come in every 5 seconds or so, whereas sampling of sender-side data happens more frequently. The RTT calculation is as dated as the RTCP data, so it doesn't belong in the newer one IMHO.

from webrtc-stats.

I was expecting the RTT to be in the inbound remote and not the outbound local.

from webrtc-stats.

@vr000m "mozRtt": 1 is in the top one, which has "type": "inboundrtp", "isRemote": true, is that what you meant?

from webrtc-stats.

OK, let's move it.

from webrtc-stats.

closing this issue because issue #78 covers this issue and PR #95 fixed the original concern.

from webrtc-stats.