WebRTC音频传输异常求助：已建立连接并传输数据但无音频样本接收

Let's break down this tricky issue step by step—your stats paint a clear picture: packets are arriving, but they're not being converted into playable audio samples. Here are the most likely culprits and how to troubleshoot them:

1. Verify Codec Negotiation Consistency #

Your inbound codec is Opus (audio/opus, 48kHz, 2 channels) with minptime=10;useinbandfec=1, but you need to confirm this matches the sender's codec configuration:

• Check the SDP offer/answer exchange for the a=fmtp:111 line on both ends. If the sender's fmtp parameters don't exactly match the receiver's, the decoder will discard packets even if they arrive.
• Mismatched clock rates or channel counts between the sender's track and the negotiated codec can also cause decoding failures. Use track.getSettings() on the sender to confirm it's capturing 48kHz stereo audio.

2. Fix Receiver ontrack Event Handling #

This is the most common root cause for "bytes received but no audio" issues, especially when using addTrack(track) without a stream parameter:

• If you omit the stream in addTrack, the receiver's event.streams will be empty. You need to manually attach the track to a MediaStream and bind it to your audio element:

  peerConnection.ontrack = (event) => {
    const audioElement = document.getElementById('remote-audio');
    if (!audioElement.srcObject) {
      audioElement.srcObject = new MediaStream();
    }
    // Ensure we don't add duplicate tracks
    if (!audioElement.srcObject.getTracks().find(t => t.id === event.track.id)) {
      audioElement.srcObject.addTrack(event.track);
    }
  };
  

• Double-check that your audio element isn't muted or set to zero volume (easy to miss!).

3. Validate Sender Audio Capture #

Even if the track shows as enabled and unmuted, the sender might not actually be capturing audio:

• Test the local track directly: Attach it to an audio element on the sender side to confirm you can hear the microphone input.
• Use the MediaRecorder API to record a short clip from the local track and play it back—this will confirm if the track is producing valid audio data.
• Check browser permissions: Run navigator.permissions.query({name: 'microphone'}) to ensure the site has active microphone access.

4. Inspect RTP Packet Integrity #

Your Wireshark capture shows packets are flowing, but let's dig deeper:

• Confirm the RTP packets' SSRC matches the ssrc value in your stats (3738623979). Mismatched SSRCs mean the receiver is routing packets to the wrong track.
• Verify RTP timestamps are consistent: For 48kHz Opus with 10ms frames, timestamps should increment by 480 per packet. Erratic timestamps will cause the jitter buffer to stall (explaining your jitterBufferEmittedCount: 0).
• Look for Opus payload corruption in Wireshark—even if packetsLost is 0, malformed payloads will fail decoding.

5. Check Decoder and Jitter Buffer Health #

Zero totalSamplesReceived and jitterBufferEmittedCount point to decoding issues:

• Check browser console logs for decoder errors (e.g., Failed to initialize Opus decoder or Invalid payload for codec).
• Some browsers restrict codec support for certain configurations—test with a simpler Opus setup (e.g., single channel, minptime=20) to rule out codec initialization bugs.

6. Rule Out Class Structure Edge Cases #

Since you're using a class-based implementation:

• Ensure your PeerConnection instance isn't being accidentally reinitialized or garbage-collected after connection setup.
• Confirm you're not calling removeTrack or modifying the track list after adding it to the PeerConnection.
• Double-check that ICE candidates are fully exchanged and the transport is in a connected state (use peerConnection.connectionState to verify).

Start with the ontrack handling and codec consistency checks—those resolve 70% of issues like this. If you're still stuck, share snippets of your track attachment and SDP negotiation code for more targeted help.

内容的提问来源于stack exchange，提问作者Jobieskii