Native WebRTC and the actual bottlenecks in camera two-way audio

[markfrancisonly]

The Android native-WebRTC stack raises a broader product question beyond the implementation details of #7137–#7141:

Which layer is actually preventing reliable two-way camera audio today, and will another client runtime materially improve it?

For roughly four years, I have tried to make two-way audio work reliably with Amcrest and Reolink cameras and doorbells. In my deployments, the Android or browser client has rarely been the limiting layer. Camera firmware, codec compatibility, limited concurrent streams, and the proxying or transcoding required through go2rtc generally fail first.

A native Android runtime can provide answer-before-unlock, CallStyle presentation, pre-negotiated media, and microphone access on plain-HTTP installations. Those are legitimate improvements. They do not, however, repair the device and transport layers where two-way audio commonly breaks.

Before significantly expanding the Android client, I think it would be useful to establish:

• Which representative cameras and doorbells have been tested end to end.
• Which codecs and go2rtc configurations are expected to work.
• Whether manufacturers or go2rtc maintainers have been involved.
• Whether the goal is broad two-way-audio reliability or primarily a more native incoming-call experience.
• Whether foreground dashboard playback needs to move out of the WebView to achieve that goal.

This is separate from the cross-stack ownership concern raised on #7137. Even with a native implementation, the app still needs deterministic coordination between native and WebView microphone/camera consumers. This Discussion is about whether the native stack addresses the principal end-to-end failure point in the first place.