# Lots of warnings in the log **URL:** \ **Category:** mediasoup libraries\ **Created:** [June 28, 2019, 5:25am UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112 "2019-06-28T05:25:01Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![mkh](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/mkh/32/145_2.png) [@mkh](https://mediasoup.discourse.group/u/mkh)\ **Post date:** [June 28, 2019, 5:25am UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/1 "2019-06-28T05:25:01Z")
I’m getting bunch of warning log messages in my production server. Should it be a concern? Here are some of them: ```auto 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 ``` ---
**Author:** ![jmillan](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/jmillan/32/9_2.png) [@jmillan](https://mediasoup.discourse.group/u/jmillan)\ **Post date:** [June 28, 2019, 5:51am UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/2 "2019-06-28T05:51:43Z")
Have you actually verified yourself what you are actually negotiating, sending (RTP content) and contrasted it with the information provided logs? ---
**Author:** ![mkh](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/mkh/32/145_2.png) [@mkh](https://mediasoup.discourse.group/u/mkh)\ **Post date:** [June 28, 2019, 9:20am UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/3 "2019-06-28T09:20:00Z")
No, how can I do that in a production server? These warnings do not happen on development. ---
**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\ **Post date:** [June 28, 2019, 11:52am UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/4 "2019-06-28T11:52:25Z")
As a general rule, logTag warnings are not bugs. ```auto 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. ```auto RTC::WebRtcTransport::OnRtpDataRecv() | DecryptSrtp() failed [ssrc:461802123, payloadType:120, seq:32416] ``` May happen when there is lot of packet lost. ```auto RTC::WebRtcTransport::OnRtcpDataRecv() | received data is not a valid RTCP compound or single packet ``` Does happen when doing screen sharing yes? ```auto 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. ```auto 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. ---
**Author:** ![mkh](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/mkh/32/145_2.png) [@mkh](https://mediasoup.discourse.group/u/mkh)\ **Post date:** [June 30, 2019, 3:48am UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/5 "2019-06-30T03:48:44Z")
> [@](#): > > Does happen when doing screen sharing yes? Yes we have screen sharing in our product. Why does it happen? > [@](#): > > 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. > [@](#): > > 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. ---
**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\ **Post date:** [June 30, 2019, 3:04pm UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/6 "2019-06-30T15:04:23Z")
> > 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: > **[mediasoup :: RTP Parameters and Capabilities](https://mediasoup.org/documentation/v3/mediasoup/rtp-parameters-and-capabilities/#RtpEncodingParameters)** > > Cutting Edge WebRTC Video Conferencing > > 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”). ---
**Author:** ![mkh](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/mkh/32/145_2.png) [@mkh](https://mediasoup.discourse.group/u/mkh)\ **Post date:** [July 1, 2019, 3:47am UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/7 "2019-07-01T03:47:45Z")
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. ```auto 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. > [@](#): > > In your comment above you are even logging “debug” logs, such as this one: > > > `RTC::Producer::ReceiveRtcpSenderReport() | RtpStream not found` Nope, this is also a warning. ---
**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\ **Post date:** [July 1, 2019, 10:13am UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/8 "2019-07-01T10:13:12Z")
> [@mkh](#): > > 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. > > ```auto > RTC::WebRtcTransport::OnRtcpDataRecv() | received data is not a valid RTCP compound or single packet > RTC::Producer::ReceiveRtcpSenderReport() | RtpStream not found [ssrc:683512549] > > ``` 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). > [@mkh](#): > > > In your comment above you are even logging “debug” logs, such as this one: > > > > > `RTC::Producer::ReceiveRtcpSenderReport() | RtpStream not found` > > Nope, this is also a warning. It will be a debug in next version. ---
**Author:** ![mkh](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/mkh/32/145_2.png) [@mkh](https://mediasoup.discourse.group/u/mkh)\ **Post date:** [July 1, 2019, 4:55pm UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/9 "2019-07-01T16:55:09Z")
> [@ibc](#): > > You can hide this error by signaling “close producer” to the server before you call `producer.stop()` in the client (for example). Then the message `RTC::Producer::ReceiveRtcpSenderReport() | RtpStream not found` might appear, no? ---
**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\ **Post date:** [July 1, 2019, 5:20pm UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/10 "2019-07-01T17:20:22Z")
Yep, but it will be a debug in next version. ---
**Author:** ![mkh](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/mkh/32/145_2.png) [@mkh](https://mediasoup.discourse.group/u/mkh)\ **Post date:** [October 22, 2019, 6:18am UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/11 "2019-10-22T06:18:48Z")
Recently I’m getting the following warning in the logs very frequently. Is this normal? `mediasoup:WARN:worker[pid:9831] RTC::Transport::HandleRtcpPacket() | no Producer found for received Sender Extended Report [ssrc:2395287560]` ---
**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\ **Post date:** [October 22, 2019, 9:01am UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/12 "2019-10-22T09:01:20Z")
It should be a “debug” instead of a “warn”. Fixed in “devel” branch (which BTW now compiles [NN times faster](https://github.com/versatica/mediasoup/commit/cf7b249eeefb1d50e32e718cf928247c864b32dd#commitcomment-35604634)). Not a bug bu expected behavior after closing a Producer. ---
**Author:** ![mkh](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/mkh/32/145_2.png) [@mkh](https://mediasoup.discourse.group/u/mkh)\ **Post date:** [October 22, 2019, 1:40pm UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/13 "2019-10-22T13:40:03Z")
But it keeps warning until the router is closed. As a result there would be bunch of logs for a long running router with frequent new/close producers. ---
**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\ **Post date:** [October 22, 2019, 1:47pm UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/14 "2019-10-22T13:47:12Z")
No, It keeps happening until the peer disconnects because the PeerConnection keeps that m= section open after closing a Producer (I.e. the webcam). It’s perfectly fine. Absolutely no issue here. ---
**Author:** ![mkh](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/mkh/32/145_2.png) [@mkh](https://mediasoup.discourse.group/u/mkh)\ **Post date:** [October 22, 2019, 5:41pm UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/15 "2019-10-22T17:41:59Z")
Okay, thanks for the clarification. ---
**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\ **Post date:** [December 2, 2019, 11:10pm UTC](https://mediasoup.discourse.group/t/lots-of-warnings-in-the-log/112/16 "2019-12-02T23:10:49Z")