Conversation
ibc
left a comment
ibc
left a comment
There was a problem hiding this comment.
Those are indeed legitimate situations that shouldn't happen if everything is good. Yes, sometimes the RTP reaches mediasoup before the Producer is created and those warnings show up, but that's ok. If we followed the rationale of this PR in the whole code then everything should be "debug" severity but a few catastrophic errors/aborts.
The client may start sending RTP before producer is ready in server side, for example. Or producer may be removed from server side before doing so in client side. Those normal situations (normal because there is always a signaling delay between client and server) generate lots of warnings which is OK in dev environments but simply unusable in big production environments where one must filter those messages in a post process pipeline otherwise. I'm fine closing this PR. One can always temporarily enable 'warn' log level and filter at another place. |
|
If the client sends RTP packets with wrong PT or SSRC etc that don't match the given RTP parameters (due to bad setup), we want to see warnings, right? |
Depending on what kind of error you are looking for. If you have a specific problem to troubleshoot you may not want to see those, which may be very well generated for every RTP producer (depending on how many producers we are talking about these may be a lot of logs). So in summary we cannot make assumptions on what to filter on the library side. The app/service needs to filter as it needs. |
2 participants
Do not use
warnfor legitimate situations.