Need to calculate RTP RTT

[ibc]

We need to calculate the RTP RTT for:

• Stats stuff.
• Better NACK algorithm (see #72).

The RTT is calculated from RR and SR. Here some math

:

[ibc]

Question: we have now rtt in RtpStreamSend, what about RtpStreamRecv?

I'll reopen the issue just in case.

[ibc]

Anyhow, let's keep this issue open also until the Chrome problem is solved:

While testing I've realised that Chrome is not setting the LSR and DLSR values on Receiver Reports (always come with a value of zero). Firefox generates the Receiver Reports properly.

This causes rtt to be 0, but not always as I've seen "rtt": 268435456 in a local test.

This is how a ReceiverReport from Chrome looks like:

<ReceiverReport>
  ssrc          : 3445359967 +1ms
  fraction lost : 0
  total lost    : 0
  last seq      : 32753
  jitter        : 1155
  lsr           : 0
  dlsr          : 0
</ReceiverReport>

[ibc]

Ok, the ugly "rtt": 268435456 seems to happen because rtt is not initialized to 0. I'll fix it.

[ibc]

Related:

• https://groups.google.com/forum/#!topic/discuss-webrtc/oWHmAJCFV1M
• https://github.com/w3c/webrtc-pc/issues/729

Also, it seems that Chrome does set the LSR field in the RR (unless no SR has been received!!!):

• https://cs.chromium.org/chromium/src/third_party/webrtc/modules/rtp_rtcp/source/rtcp_receiver.cc?cl=GROK&gsn=GetReportBlockInformation&l=495

[ibc]

@jmillan I'm afraid we are not routing SDES packets at all:

https://github.com/ibc/mediasoup/blob/master/worker/src/RTC/Peer.cpp#L905

Not sure if that may cause Chrome to not correlate received SR...

[ibc]

Now I'm really afraid. In Chrome rtcp_receiver.cc:

void RTCPReceiver::HandleXrDlrrReportBlock(const rtcp::ReceiveTimeInfo& rti) {
  if (registered_ssrcs_.count(rti.ssrc) == 0)  // Not to us.
    return;

  // Caller should explicitly enable rtt calculation using extended reports.
  if (!xr_rrtr_status_)
    return;

  // The send_time and delay_rr fields are in units of 1/2^16 sec.
  uint32_t send_time_ntp = rti.last_rr;
  // RFC3611, section 4.5, LRR field discription states:
  // If no such block has been received, the field is set to zero.
  if (send_time_ntp == 0)
    return;

  uint32_t delay_ntp = rti.delay_since_last_rr;
  uint32_t now_ntp = CompactNtp(clock_->CurrentNtpTime());

  uint32_t rtt_ntp = now_ntp - delay_ntp - send_time_ntp;
  xr_rr_rtt_ms_ = CompactNtpRttToMs(rtt_ntp);
}

So, it's 100% confirmed that Chrome just calculates its send_time_ntp if it receives a XR report, as this thread confirms.

[ibc]

Humm, I think I was wrong in my previous and too quick analysis. After checking a bit more both rtcp_receiver.cc and rtcp_sender.cc, it looks to me that Chrome just does not set those LSR and DLSR fields at all, never. Instead, it calculates (and expects the remote to also calculate) RTT based on XR reports.

[fippo]

uhm... I see nonzero LSR and DLSR fields all the time...

[ibc]

uhm... I see nonzero LSR and DLSR fields all the time...

Do you let XR reports reach remote browsers?

[fippo]

I don't see any XR reports. I did a quick check and disabled SR and then LSR and DLSR stay 0. So it looks like you want to generate those

[ibc]

Generate Sender Reports? We already do that.

But, now that you say it... we don't generate nor forward SDES stuff right now. I don't think it's relevant here, but who knows... May be Chrome "ignores" SR if no SDES was received first?

[fippo]

Filtering SDES but not SR still results in RR with LSR and DLSR set for me. So Chrome somehow dislikes your SR?

[ibc]

Filtering SDES but not SR still results in RR with LSR and DLSR set for me.

Nice to know.

So Chrome somehow dislikes your SR?

Humm, I don't think so. In fact, in the past we had a audio&video sync problem in Chrome/Firefox due to a wrong lsr: #58. Once fixed, the sync problem went away in both Chrome and Firefox, so I do expect that Chrome is accepting our SR.

Is there any way to know if Chrome does not like "something" in out Sender Reports? chrome://webrtc-flags just shows the RTT for senders but not for receivers...

[ggarber]

If everything looks good in the SR then you can compile Chromium and add logs if the existing ones are not showing anything :(

I always had proper LSR/DLSR and never sent an XR so far. You are using multistream and we are not so maybe there is some difference there.

[ibc]

If everything looks good in the SR then you can compile Chromium and add logs if the existing ones are not showing anything :(

I hope Chrome logs may help without having to compile it... :(

[ibc]

Mmmmmm, my fault:

So Chrome somehow dislikes your SR?

Humm, I don't think so. In fact, in the past we had a audio&video sync problem in Chrome/Firefox due to a wrong lsr: #58

The fix was in the Receiver Report rather than in the Sender Report, so yes, there may be a problem in the SR.

[ibc]

Good news, indeed Chrome does not like our SR:

69814:32515:0326/225918.677785:WARNING:sender_report.cc(52)] Packet is too small to contain all the data.

Here.

:)

[jmillan]

@fippo @ggarber

Thanks a lot for the comments. The issue was with the RTCP common header count value for the Sender Report compound packet, which was erroneously set to 1 when it must be 0 given that we are not sending Receiver Reports in such packet.

[ibc]

👍 👍 👍 👍