How you monitor this for you ?
My apologise, i did it a long time ago already, i just saw what you meant.
The DTLS state is connected for me.
So that mean that the connection with the server work.
Both producer and consumer have the state conencted, but i have not media stream running.
Here is my consumer log:
Everything looks fine for me.
On this grey box the video stream should be playing:
You track is ‘muted: true’, that is why it is causing this issue. On server side you may be creating consumer with ‘paused: true’ and not ‘resuming consumer’ after it is created. Do verify that.
This is how i created my consumer in a function:
const consumer = await transport.consume({
producerId: stream.producer_id,
rtpCapabilities: rtpCapabilities,
paused: false,
});
Even in my front end i force to play the video.
I see, strange, you mentioned you were using docker. Usually this type of stream not flowing issue happens when there is some ip, port issue. Do verify that.
Yes but does the connection state should failed in this case ?
Or is it not related ?
Maybe the connection can work but the media stream can’t be played because of that ?
I just saw the track is muted, i think it wasn’t.
I try to change that and come back.
And something i don’t understand, why in the documentation do we have the choice to add ice servers in transport options if we don’t need one with mediasoup ?
Ice servers are needed on client side but not on server side as it is ice lite.
Ok in case i am not using an s fu sserver with mediasoup ?
Do you have an idea why my media track is muted to true ?
And how to change it ?
Ice servers are still needed in normal p2p webrtc call to establish connection.
This muted true is mainly due to producer not producing and if it not producing correctly then consumer will have this type of issue.
On your producer side in chrome://webrtc-internals you can check bits/sec being sent if it is 0 then definitely issue.
And this usually happens when you have port related issues.
Their are many topics in this platform related to docker issues. Try exploring them.
Also try it without docker, make it work and then later on solve the docker config related issue.
Consumer is an envelope for the transceiver.receiver, and the track is always created and present in the transceiver. You cannot rely just on its existence. Check RTP stream statistics.
These can be used in case the client is unable to connect to mediasoup’s worker directly and need a relay.
consumer.track is always created. As you have been told you must check whether there is incoming RTP traffic or not on that inbound track.
I did this :
const rtpReceiver = consume.rtpReceiver;
const statsReport = await rtpReceiver.getStats();
statsReport.forEach((report) => {
if (report.type === 'inbound-rtp') {
console.log(`Bytes received: ${report.bytesReceived}`);
console.log(`Packets received: ${report.packetsReceived}`);
console.log(`Packets lost: ${report.packetsLost}`);
}
});
And i have no packets receive.
Here the log:
Bytes received: 0
Packets received: 0
Packets lost: 0
I’m afraid you must read how these things work rather than trying to run random things. What do you expect if you get stats just once after creating the consumer? Of course you will see 0 everywhere.
As you were told:
- Ensure if transport is connected at ICE and DTLS level.
- Ensure you don’t create the mediasoup side Consumer in paused mode.
- Checks stats periodically via consumer.getStats() or via chrome://webrtc-internals
Please check those things in depth instead of just pasting your code.
This is what i get for producer side without connecting any consumer yet:
And here the graph for media source and the transport
Sorry, I cannot help. You ignore most of what it’s told to you and just paste things for us to check.