Audio is not rendered from one peer in PTT mode

[dbkr]

Describe the bug
This is a bug to track the failures we've been seeing in PTT mode where audio packets are received by the browser but it doesn't play them and we don't see the PTT rings animating.

To Reproduce
Steps to reproduce the behavior:

1. Enter PTT call on browser A
2. Enter the same call on browser B
3. Click the 'back' button to exit the call on browser B, then click on the same call & rejoin
4. Press PTT button on browser A, check if audio is heard on browser B
5. Repeat above two steps until you hear no audio and no rings animate

'browser A' was initially an Android device running element call in a webview. It does appear to be slightly easier to reproduce the bug with this setup. Some of us have been unable to repro with two desktop browsers.

We are assuming that there are other ways that this bug can be triggered, but this seems to repro the bug where closing browser B & re-visiting the URL for the call does not.

Expected behavior
Audio should be heard from browser B when pressing PTT button on browser A

[dbkr]

What we know so far:

• From webrtc-internals, we can see that browser B is receiving audio data, and this data appears to be non-silence judging by the way the amount of data received increases on audio activity.
• However, there are no audio samples received in the inbound audio stream
• RTPInboundAudioStream shows almost all packets are being discarded (packetsDiscarded ~= packetsReceived)

[dbkr]

It looks like the reason the packets aren't making it anywhere is because the jitter buffer is somehow getting confused and throwing them away. The number of jitter buffer flushes keeps increasing, so the jitter buffer is filling up but never emitting anything.

It looks like somehow the jitter buffer is getting into a mode where it's frequently flushing but still never actually getting into a mode where it can emit packets.

Comparison of the outbound audio stream on the sender & inbound on the receiver:

So the timestamps correspond, although unsure exactly what [lastPacketReceivedTimestamp] is, which appears to be 18 seconds behind.

At this point, we probably need to start looking into WebRTC's jitter buffer code, and/or just workaround it in the app by, eg. restarting the call if we see packets arriving but no media. 😢