As much as this is a bit embarrassing I'd say theres no malice behind it but rather optimisation.
You see, it takes a bit of time to fire up the audio processors on iOS. So if you'd only do this as the call is accepted you'd have a second of silence before all systems were go.
What they have done is allocate an instance of the audio handler when the call comes in. So when the call is accepted audio is ready to go immediately.
The problem is that you need to mute the audio handler and then un-mute when the call is accepted. What happened here is that _something_ triggered the un-mute to happen immediately. leaving the audio go through even though the call isn't answered yet.
Calls to have Tim % Co. fired for this are just ridiculous, grow up kids, grow up. This is a pretty small bug, a bit embarrassing alright but it's not a 'gate'.
You see, it takes a bit of time to fire up the audio processors on iOS. So if you'd only do this as the call is accepted you'd have a second of silence before all systems were go.
What they have done is allocate an instance of the audio handler when the call comes in. So when the call is accepted audio is ready to go immediately.
The problem is that you need to mute the audio handler and then un-mute when the call is accepted. What happened here is that _something_ triggered the un-mute to happen immediately. leaving the audio go through even though the call isn't answered yet.
Calls to have Tim % Co. fired for this are just ridiculous, grow up kids, grow up. This is a pretty small bug, a bit embarrassing alright but it's not a 'gate'.