Lots of warnings in the log

I’m getting bunch of warning log messages in my production server. Should it be a concern? Here are some of them:

RTC::WebRtcTransport::OnRtpDataRecv() | no suitable Producer for received RTP packet [ssrc:873299334, payloadType:96]
RTC::WebRtcTransport::OnRtpDataRecv() | DecryptSrtp() failed [ssrc:461802123, payloadType:120, seq:32416]
RTC::WebRtcTransport::OnRtcpDataRecv() | received data is not a valid RTCP compound or single packet
RTC::Producer::ReceiveRtcpSenderReport() | RtpStream not found [ssrc:3928907376]
RTC::RtpStreamRecv::OnTimer() | RTP inactivity detected, resetting score to 0

Have you actually verified yourself what you are actually negotiating, sending (RTP content) and contrasted it with the information provided logs?

No, how can I do that in a production server? These warnings do not happen on development.

As a general rule, logTag warnings are not bugs.

RTC::WebRtcTransport::OnRtpDataRecv() | no suitable Producer for received RTP packet [ssrc:873299334, payloadType:96]

This is completely normal. It just means that mediasoup received a RTP packet from the client (browser) before the server side transport.produce() ended. Nothing happens.

RTC::WebRtcTransport::OnRtpDataRecv() | DecryptSrtp() failed [ssrc:461802123, payloadType:120, seq:32416]

May happen when there is lot of packet lost.

RTC::WebRtcTransport::OnRtcpDataRecv() | received data is not a valid RTCP compound or single packet

Does happen when doing screen sharing yes?

RTC::Producer::ReceiveRtcpSenderReport() | RtpStream not found [ssrc:3928907376]

Happens when closing a Consumer. It’s deleted in the server but the browser keeps sending ReceiverReports for it. Just ignore.

RTC::RtpStreamRecv::OnTimer() | RTP inactivity detected, resetting score to 0

What’s the bug there? It just means that the browser has stopped sending a specific simulcast stream (due to CPU usage in the browser, etc). It happens all the time.

Absolutely nothing to worry here. Anyway, please, when you get some “suspicious” warning navigate the code to find where those happen.

Yes we have screen sharing in our product. Why does it happen?

But simulcast is disabled. What now? This one is the most frequent message that happens all the time.

So why warning and not info if there is nothing to worry about? These are developer logs so should warn about some thing wrong. This way hundreds of lines are produced every day and the real warnings or errors are lost.

Does happen when doing screen sharing yes?

Yes we have screen sharing in our product. Why does it happen?

Those may be non supported RTCP messages that are just produced by Chrome when screen sharing. They may be Extended Reports (not sure). If so, there is an ongoing PR for them:

It just means that the browser has stopped sending a specific simulcast stream (due to CPU usage in the browser, etc)

But simulcast is disabled. What now? This one is the most frequent message that happens all the time.

By default mediasoup monitors received RTP and checks for RTP inactivity (which happens if no RTP packet is received in ~300 ms). This is specially needed when simulcast is used since, currently, browsers may stop sending the highest or medium simulcast streams at any time without any kind of indication, so mediasoup needs to react fast to switch to another available stream in all consumers (otherwise those consumers would get frozen video for some seconds).

In screen sharing this is not a goof idea since when static content is being transmitted, the RTP cadency may be very low so it’s perfectly possible that there is lack of RTP during more than those ~300 ms. For those cases, enable the dtx option in the RtpEncodingParameters:

Absolutely nothing to worry here. Anyway, please, when you get some “suspicious” warning navigate the code to find where those happen.

So why warning and not info if there is nothing to worry about? These are developer logs so should warn about some thing wrong. This way hundreds of lines are produced every day and the real warnings or errors are lost.

Just case about “errors” and not so much about “warnings”. In your comment above you are even logging “debug” logs, such as this one:

RTC::Producer::ReceiveRtcpSenderReport() | RtpStream not found

You should not log “debug” logs in production and should not really enable logTags (just if logLevel is “error”).

Well I could reproduce some of them:

RTC::RtpStreamRecv::OnTimer() | RTP inactivity detected, resetting score to 0

This happens if closing the producer in the server has a delay of 500+ ms after the client corresponding producer is closed (may happen in bad network conditions). It happens even if simulcast is disabled for both audio and video.

RTC::WebRtcTransport::OnRtcpDataRecv() | received data is not a valid RTCP compound or single packet
RTC::Producer::ReceiveRtcpSenderReport() | RtpStream not found [ssrc:683512549]

These two happen right after starting the screen sharing. The first message appears only for Chrome.

Nope, this is also a warning.

At mediasoup we need to check if RTP is no longer active. Yes, it may happen due to many reasons. If close signaling takes long (500ms+) such a warn will be printed because mediasoup has detected lack of RTP. What is the exact problem here? We cannot just “hide such a log” just because it’s not a real failure in your scenario. It may happen that, due to network failure, no RTP is received. If the Producer has not been closed in the server we need to report “RTP inactivity”.

You can hide this error by signaling “close producer” to the server before you call producer.stop() in the client (for example).

It will be a debug in next version.

Then the message RTC::Producer::ReceiveRtcpSenderReport() | RtpStream not found might appear, no?

Yep, but it will be a debug in next version.