> audio and video capture has to start going before call is actually established at signaling level, in order to minimize call establishment delay. Audio maybe going through Bluetooth, for example, and waking up Handsfree mode of BT may take 1-2 sec
As a user, while I can accept capture starting before I answer, I cannot accept sending. I understand how it helps the speed of establishing calls.
But it means the only thing needed to spy on me from that is a software change ON THE OTHER SIDE. No way to know from my side if I'm good or not.
But your comment it missing the point. Parent commenter said it needs to start recording audio and video earlier, and a combination of other circumstances cause the device to send the data. Nobody argues this is acceptable.
I am not saying whether sending happens at the establishment phase or not - it's just that when your AV capturing is started and even encoding goes on - it's a matter of dropping the actual AV packets or sending them at the network stack/jitter buffer level. By the way, if not for privacy/security, it's actually very useful to start sending AV stream over the network, to pre-heat the network & test its throughput. For example, cellular data bitrate ramps up only when you actually send data, and it takes some delay to ramp up at more power-hungry levels and for cellular to even test what's possible. Also, estimating network bandwidth for the application layer requires measuring the round-trip time for a few seconds...
As a user, while I can accept capture starting before I answer, I cannot accept sending. I understand how it helps the speed of establishing calls.
But it means the only thing needed to spy on me from that is a software change ON THE OTHER SIDE. No way to know from my side if I'm good or not.