Muted is not for audio, it is for video also. It is related to track, if it is muted then it means data is not being transmitted/received.
Looks all good, make sure to resume the consumer as well. In v3 we create consumer in paused state and the resume it later on, it is recommended. Check if there is something like this in v2.
Also you mentioned about third connection, you need to check it why it is being created more specifically you need to get the track id and compare it in webrtc-internals to see which peer connection is giving you stream.
each peer has two peerConnections, one for the send and one for the recv, I assume. maybe the extra one is irrelevant regardless? because it becomes closed and disappears eventually.
I had three peers into the same room on the same browser, and here’s what I got.
I let the server close a peer after having its recv transport not connected in 30secs, so there’s a “closed” state in this screenshot.
all of them were connected and the “new” closed and disappeared very soon. leaving the fine connections.
within each pid, there was one local and one remote, having both succeeded, I think that should’ve been enough to get things working.
the problem should be on the server-side, any possible causes?
router.post(‘/joinRoom’, async (req, res) => {
//console.info(“join params:”,req.body);
const params = req.body;
const room = getRoom(params.id);
try{
const msp = await room.receiveRequest(params.request);
peerRoomMap[params.request.peerName] = params.id
res.status(200).json({code:“000000”,data:{msp}})
}
catch(e){
console.error(“join failed:”,e)
res.status(500).json({code:“000001”,data:{e}})
}
})
router.post(‘/leaveRoom’, (req,res)=>{
const params = req.body;
const rid = peerRoomMap[params.name]
removePeer(rid,params.name);
delete peerRoomMap[params.name]
res.status(200).json({code:“000000”})
})
router.post(‘/connectPeers’, async (req,res)=>{
const params = req.body
const room = getRoom(params.id)
try{
//console.info(“processing msp:”,params.request);
const peer = room.getPeerByName(params.name)
const msp = await peer.receiveRequest(params.request)
res.status(200).json({code:“000000”,data:{msp}});
}
catch(e){
console.error(“connect failed:”,e);
res.status(200).json({code:“000001”,data:{e}});
}
})
here’s everything I did with the rooms, “/connectPeers” and “/joinRoom” are the routes I handle the mediasoup-protocol requests. there were no other processes.
That extra peer is ok, it happens on my side as well so it can be ignored, if all other peer are in connected state then all is ok.
Console the tracks being received expand it in console and send me screenshot need to see the attributes.
Apart from that if you can deploy it somewhere and send me the link then i can better look into it, as it is really difficult to guess the issue.
You are creating new application or it is and old application? If it is old then was it working ok earlier? If it is new app then why you are using v2? you should use v3.
a new application.
I’m gonna switch to v3 right now.
couldn’t install v3 last week due to some dependencies that I consistently failed to download from the given github url. at that moment I decided to try v2.
today I found a mirror of v3, gotta start over real quick.
Man, go with v3, v2 is quite old and very much different from v3. Go with v3, 3.9.0. you will surely be on right path.