We have been struggling for a couple weeks now with bluetooth output not being picked up correctly on iOS (sound goes out to iphone speaker instead of bluetooth headsets). We found this discussion https://bugs.webkit.org/show_bug.cgi?id=282939 with a workaround that seems to work. Except 2 things 1. The mic never gets released after the call. Working on this, but if anyone has an idea.... 2. Just did a test with my crappy car audio system. Audio output worked fine, but input failed. Now, looking at the logs, I see a really strange wavreform, which makes me thing this could be a background denoizing interference issue (car being so loud it's actually cancelling ALL audio input 😄 )). The call ID is 590fb800-caff-449f-8e08-592cf10155a6 Could you have a look and let me know if you see anything that confirms this theory?

@jeromec8194 I looked into the logs for call ID 590fb800-caff-449f-8e08-592cf10155a6, and here's what I found, and According to what I'm seeing, this appears to be a timing/buffering issue, not specifically your car's background noise cancellation as initially theorized. The microphone was initialized successfully (shown as "state": "playable" in the logs), but there was a problem with the Text-to-Speech (TTS) buffer synchronization. As for your Bluetooth audio issues: 1. The logs don't contain VAD (Voice Activity Detection) or denoiser entries that would help confirm the background noise cancellation theory 2. The mic not being released after calls is likely related to a known WebKit bug (#282939) in iOS Safari with Bluetooth audio routing in WebRTC contexts Here are the next steps I recommend: 1. Implement the AudioSession API workaround for iOS 16.4+ devices:

ts
   // Before starting microphone
   if (navigator.audioSession) {
     navigator.audioSession.type = 'auto';
   }
   
   // After getting microphone access
   if (navigator.audioSession) {
     navigator.audioSession.type = 'play-and-record';
   }
   
   // When done with the microphone
   if (navigator.audioSession) {
     navigator.audioSession.type = 'playback';
     navigator.audioSession.type = 'auto';
   }

2. Try disabling audio processing when getting the media stream:

javascript
   navigator.mediaDevices.getUserMedia({
     audio: {
       autoGainControl: false,
       echoCancellation: false,
       noiseSuppression: false
     }
   })

3. Collect more detailed logs during your next test call by enabling browser console logs to capture WebRTC negotiation and device selection events The core issue appears to be related to how iOS handles audio routing with WebRTC, which is a known problem that Apple has been slow to address.