no Consumer found for received Receiver Report

mediasoup libraries
1

Hi,

I’m in need of a bit of help with some unexpected debug messages that are happening in mediasoup, and I’d like to make sure they won’t be harming the connection quality:

My app creates a WebRtcTransport which then has a video Consumer (from another webrtc transport which has a video Producer). No simulcast is being used, so types are all “simple”.

Not sure if relevant, but if I log the Producer’s RtpParameters, it has an encodings array like this:

Producer RtpParameters:
{
  // ...
  "encodings": [
    {
      "ssrc": 3312219837,
      "rtx": {
        "ssrc": 793727772
      },
      "dtx": false
    }
  ],
  "rtcp": {
    "cname": "Iz0kr3XInDNYudpv",
    "reducedSize": true,
    "mux": "rtcp-mux"
  }
}

Similarly, logging the Consumer in question (all Consumers, really) has an encoding for the video and another one for the RTX:

Consumer RtpParameters:
{
  // ...
  "encodings": [
    {
      "ssrc": 160973207,
      "rtx": {
        "ssrc": 160973208
      }
    }
  ],
  "rtcp": {
    "cname": "Iz0kr3XInDNYudpv",
    "reducedSize": true,
    "mux": true
  }

From this Consumer, an SDP Offer is generated, to be sent to a receiver browser. The video SSRC lines in this generated SDP look like this:

a=ssrc:160973207 cname:Iz0kr3XInDNYudpv
a=ssrc:160973208 cname:Iz0kr3XInDNYudpv
a=ssrc-group:FID 160973207 160973208
a=rtcp-mux
a=rtcp-rsize

Then, I’m constantly seeing these debug messages coming from mediasoup:

  mediasoup:Channel [pid:5497] RTC::Transport::HandleRtcpPacket() | no Consumer found for received Receiver Report [ssrc:160973208] +29ms
  mediasoup:Channel [pid:5497] RTC::Transport::HandleRtcpPacket() | no Consumer found for received Receiver Report [ssrc:160973208] +201ms
  mediasoup:Channel [pid:5497] RTC::Transport::HandleRtcpPacket() | no Consumer found for received Receiver Report [ssrc:160973208] +34ms
  mediasoup:Channel [pid:5497] RTC::Transport::HandleRtcpPacket() | no Consumer found for received Receiver Report [ssrc:160973208] +196ms
  (lots more)

these repeat approx. every 500 to 1000ms, so I guess whenever Chrome sends an RR to mediasoup, and I’ve noticed it happens especially when there is packet loss bursts (introduced with a tool).

The only thing I can see that might be wrong here is that the SDP Offer generated from mediasoup for Chrome contains a=ssrc cname fields, but none of the a=ssrc msid, a=ssrc mslabel and a=ssrc label that SDP Offers from Chrome usually contain.

However, I don’t see how that would confuse mediasoup when receiving the RR packets from Chrome, seeing that the lookup is done by SSRC and in fact, the log message does mention the correct SSRC number (160973208) as present in both the Consumer params and the SDP Offer sent to the receiver Chrome.

Is there any obvious mistake being done here? Some tip that could help me work this issue out?

2

mediasoup doesn’t consider RTCP ReceiverReports for the RTX stream, that’s all. It does it in Producer side, but not in Consumer side, so when a RR is received in the mediasoup Transport it just does lookup for audio/video Consumers but not for their RTX related streams.

We may realize of it and just silently ignore the RR. I think there is a map of RTX ssrcs in Transport that could be used for it.

3

Thanks! I just needed to know that it would not cause a lack of important information in the mediasoup internals for whatever handling of media. If this is an “expected” thing to happen, then good to know

(yeah if this is actually expected, a silent ignore would maybe be better, because Chrome seems to be sending a lot of RR with the RTX ssrc, some times making the debug logging mostly unreadable, cluttered with so many repeated messages)

4

What about a PR? :grinning:
We have a mapRtxSsrcToSomething in Transport class already AFAIR.

5

Well I could try, yeah :slight_smile: will let Mica know

1 Like
6

You were right, it was trivial to add, given that all the data was just there, only needed to be used to prevent unnecessary debug lines: