Media Stream Not working when using latest verion

Hi, I am creating a prototype for a voice chat application.

  • Mediasoup-client : 3.6.51
  • Mediasoup : 3.9.2
  • node version 16.13.1
  • Client Windows electron Nodejs
  • Server Linux Nodejs
  • Server is using http server for signaling

I have followed the documentation for V3.

GOAL:
Create a microphone stream produce to server and consume by another client.

PROBLEM:
The receiver/consumer is receiving a valid stream track from the server but when playing, nothing is happening. I have checked to see if it’s enabled and not paused.

STEPS:
Producer → windows client. →
→ Create transport on server → send details to client → create producer transport
→ Create microphone stream → create producer from transport → send to server details from transport event → create producer on server
→ Connect transports when even is called on client

Consumer → windows client. →
→ Create transport on server → send details to client → create consumer transport
→ Request from server consumer stream → create consumer on server → send details to client → create consumer from details
→ Connect transports when even is called on client
→ Create stream from consumer track
→ Play stream

I’m receiving the success events from ‘newproducer’ and ‘newconsumer’.
Ive also tested the audio stream on the producer client before creating the producer and it does indeed play audio.

I am confused, what could be the problem?

Sounds right, you’re establishing the transport connection and streaming to and from. I would ask if this is performed through browser (as client) and if so is there warnings thrown in console? Auto-play tends to be a problem.

I tried in the browser and I’m receiving no errors. I did notice however that the track id on the producer client is different than that of the consumer client.

Any ideas of what the problem may be?

The ID’s will differ each end, to not mistake the transport and it’s connectee’s/etc.

I’d check in browser the webrtc-internals and see if there’s packets being sent, if there is I’d be more aimed at it being a client issue.

Auto-play policies may be something to look into if client is absolutely getting transmission but it’s not working. (webrtc-internals)

I check the console and I’m not receiving any sort of Audiocontext chrome auto-play error/warning.
I also sniffed packets on the producer, the audio stream is sending to the server.

The track of the consumer client is created with the transceiver. It doesn’t mean that anything is being received, nor even that the connection is established.
What are the states of the transports?

Yes, the connection state on both the producer and consumer are connected. I did wireshark the consumer and I don’t see any stream packets from the server.

I see that dtlsState is stuck on connecting for the consumer transport:

[
  {
    bytesReceived: 3606,
    bytesSent: 2242,
    dtlsState: 'connecting',
    iceRole: 'controlled',
    iceSelectedTuple: {
      localIp: '0.0.0.0',
      localPort: 48539,
      protocol: 'udp',
      remoteIp: '192.168.3.96',
      remotePort: 64479
    },
    iceState: 'completed',
    probationBytesSent: 0,
    probationSendBitrate: 0,
    recvBitrate: 224,
    rtpBytesReceived: 0,
    rtpBytesSent: 0,
    rtpRecvBitrate: 0,
    rtpSendBitrate: 0,
    rtxBytesReceived: 0,
    rtxBytesSent: 0,
    rtxRecvBitrate: 0,
    rtxSendBitrate: 0,
    sendBitrate: 0,
    timestamp: 6485740268,
    transportId: '64f837d4-94ae-48a0-9bf3-709e325c579c',
    type: 'webrtc-transport'
  }
]

Any idea why?

It’s probably some network related thing. That 0.0.0.0 localIp looks suspicious.

What does your network layout look like? It looks like you’re running inside of a private NAT. Are both hosts behind the same NAT? What are you passing to listenIp to createWebRtcTransport?

The client and Server are on different subnets within the same local network but I’ve already checked my firewall rules and logs and nothing seems to be blocking between the two.
I also don’t see a reason of why the producer transport works but consumer doesn’t.

listenIps: [
{
		ip: '0.0.0.0',
		announcedIp: '192.168.0.208'
}]

Maybe try this instead? The announcedIp is for environments (like AWS) where they have an external NAT that routes to private IPs.

listenIps: [{ ip: '192.168.0.208' }]

I don’t know if that will fix your problem. If it’s still stuck, you might try reverting to older versions of mediasoup-client. The DTLS roles were changed in version 3.6.45 for send-transports. I doubt that’s related, but if you’re stuck you might try it.

I tried the listenIps as well as downgrading the version of mediasoup-client and still no luck.

I enabled debugging on the server:

I figured out the problem, the dtls parameters when connecting the consumer transport was scuffed.