can consume on desktop browser, but can't consume on any mobile browser


This is my first post and I should start by saying how awesome the mediasoup project is. It’s such a great design and very easy to use. The fact that I was able to get up and running with mediasoup in just a few hours, without much knowledge of webrtc, is a testament to its creators.

I’m trying to debug an issue that I am experiencing with the JS mediasoup-client 3.6.24 on mobile browsers and I’m not entirely sure where to start. I was hoping to get a few pointers, if possible.

In my app, which is all browser-based, I have one audio producer (using the js mediasoup client) and many audio consumers (also using the js mediasoup-client).

For the consumers, everything works great in all desktop browsers I have attempted, even Safari. It works great.

However, when I try any browser on the mobile phone - safari on ios, chrome/firefox/brave on android - I get no audio.

On mobile chrome (debugging using the remote developer tools), I can verify that audio is allowed (audio context is resumed during an onclick event) and capable on the brower, the consumer has an audio track and that the consumer is not paused and the track is not muted. However, getStats() on the consumer (when parsed) shows roughly this:

  1. audio:

    1. bitrate: NaN
    2. bytesReceived: 0
    3. concealedSamples: 0
    4. concealmentEvents: 0
    5. detached: false
    6. ended: false
    7. fecPacketsDiscarded: 0
    8. fecPacketsReceived: 0
    9. headerBytesReceived: 0
    10. id: “RTCMediaStreamTrack_receiver_49”
    11. insertedSamplesForDeceleration: 0
    12. isRemote: false
    13. jitter: 0
    14. jitterBufferDelay: 0
    15. jitterBufferEmittedCount: 0
    16. kind: “audio”
    17. mediaType: “audio”
    18. packetRate: NaN
    19. packetsLost: 0
    20. packetsReceived: 0
    21. remoteSource: true
    22. removedSamplesForAcceleration: 0
    23. silentConcealedSamples: 0
    24. ssrc: 483859884
    25. timestamp: 1603837922640.331
    26. totalAudioEnergy: 0
    27. totalSamplesDuration: 0
    28. totalSamplesReceived: 0
    29. trackId: “RTCMediaStreamTrack_receiver_49”
    30. trackIdentifier: “edb41883-a976-4e93-b5e0-1f1e674ece34”
    31. transportId: “RTCTransport_0_1”
    32. type: “track”

What would be stopping it from consuming just on mobile browsers? fWIW, I can hook up mobile browsers with audio using the webrtc api just fine. Am I missing some mobile web browser restriction that only applies to mediasoup? I thought mabye rtp capabilities might not be matching up, but all ends seem to be using the same opus codec for audio.

Debugging web apps on mobile is pretty painful, so any tips you have on where to look and how would be most helpful

thanks for any advice!

Honestly no idea, but here two things you could/should do always in these cases:

  1. Ensure that the recv transport is connected.
  2. Do the same in the server side transport.
  3. Check status in server side recv transport and consumer.

Thanks so much for the reply. I was able to check and verify all of the things you mentioned.

In the process, I also check the transportOptions passed from the server to the js device.createRecvTransport()

In it I saw this:

  1. iceCandidates: Array(2)
  2. 0: {foundation: “udpcandidate”, ip: “”, port: 8960, priority: 1076558079, protocol: “udp”, …}
  3. 1: {foundation: “tcpcandidate”, ip: “”, port: 8155, priority: 1076302079, protocol: “tcp”, …}

Which, of course, won’t work on my phone that connects to my development laptop over local WIFI at home.

I was setting the listenIps in the server incorrectly!

In my home development setup, I tell my wifi gateway to hand out fixed IPs and then set up a local DNS that always points to that IP (eg local.myhostname.tld -> 192.168.x.x, etc). This allows all of my local wifi connections to connect to the server by name (which is needed for setting up the https/TLS that is needed for web audio and webrtc and such in browsers).

Anyway, for my particular setup, I just needed to switch the server.listenIps.ip from to my externally visible IP of 192.168.x.x. Now all is working great and as expected!

This is why it worked in all of my desktop browsers that were all running on and not my phones that were on their own LAN IPs

Thanks so much for the reply and for this great software. Apologies for the noise. Perhaps my writeup here will serve someone in the future that encounters a similar issue/snafu.

Just in case you missed it: