True.
Further, this shows how many people who commented on this ARE NOT developers. Any developer could easily come up with a scenario to explain how this happened. Here's two theoretical methods I came up with to connect FaceTime calls, with one being susceptible to the bug:
Scenario One:
- Person initiates a FaceTime call on iPhone A to iPhone B.
- iPhone A connects to the server and requests connection.
- Server contacts iPhone B and requests a FaceTime call.
- iPhone B puts up the FaceTime dialog to allow the person to answer or decline the call.
- If iPhone B declines the call, a message gets sent back through the server to iPhone A notifying them of the declined call.
- If iPhone B accepts the call, it starts a connection back to the server to stream audio/video.
- iPhone A is notified of the accepted call, starts receiving the stream from iPhone B, and it also creates a streaming connection back to the server for audio/video.
- iPhone B starts receiving the audio/video stream from iPhone A.
- When either person ends the call all streaming is stopped and both iPhones are dis-connected from the server.
The problem we're having with this is the delay between each iPhone starting to stream and connecting the the server. This manifests itself as a wait of a couple seconds before each party can see/hear the other person. Developers are asked to speed this process up.
Scenario Two: Faster Connections.
- iPhone A initiates a FaceTime call.
- iPhone A immediately starts streaming audio/video to the server.
- The server connects to iPhone B and requests a FaceTime call.
- iPhone B, upon receiving this request also immediately starts streaming audio/video back to iPhone A via the server.
- On both iPhones the audio/video stream is kept muted for privacy until the call is accepted.
- When iPhone B accepts the call the audio/video stream is immediately un-muted and both parties have an instant audio/video connection.
- If iPhone B declines the call both iPhones cease streaming audio/video and end their connection.
Pretty simple. In an effort to make connections appear fast & seamless the streaming is initiated right away, but kept hidden until someone answers. The bug probably occurred when they added a second person and the system accidentally took that to mean the request was accepted, hence the audio/video being un-muted and the first person seeing the stream from the second person.
So, a simple bug inside a feature intended to speed up connections resulted in someone's stream being un-muted when it wasn't supposed to.