connection.
For legacy reasons, the call sender used to wait until after receiving
the call answer before sending the ICE updates. The primary motivation
was that if the receiving user hadn't accepted a new identity change,
rather than just seeing one "Tap to Accept New Safety Number" messages
for a call, they'd see one for the call offer and then a dozen more as
ICE updates trickled in.
We changed that behavior long ago, and effectively all clients will
avoid that case, while sending ICE updates immediately will allow calls
to connect without having to wait for an additional serialized round
trip between the caller and call recipient.
// FREEBIE
Assigning dataChannel sometimes happens after iceConnect.
Fixes symptom where Alice calls Bob.
Bob answers and sees the call UI as normal
but Alice sees call as continuing to ring
// FREEBIE
By centralizing AudioSession management onto the AudioService, we can
avoid enabling the RTCAudioSession while we're mid-ring.
Also allows us to centralize and remove redundant audio session logic.
// FREEBIE
It's not clear why we were ever dispatching `sync` here.
Before this:
Place a call
See "connecting..."
Hang up
UI hangs for ~5 seconds
See "call failed" on CallKit screen
Press "cancel" on CallKit screen
returned to responsive app.
// FREEBIE
Now, by default, we only use TURN for incoming calls from unknown
contacts. We will potentially directly connect for outgoing calls and
for incoming calls from known contacts.
Optionally, the user can disable direct connection altogether, at the
cost of some call quality.
// FREEBIE
Distinguish between localHangup, remoteHangup, and call failure.
This allows us to put CallKit in the proper state, ready to receive new
calls without having a backlog of phantom calls which haven't been
properly removed.
Note the "call error" occurs at the point ICE fails, which takes a
while. Anecdotally, like 10 seconds, which feels like a long to be
talking into the ether.
I briefly considered failing at 'disconnected', which happens much
sooner, but that's actually a recoverable state. E.g. if you toggle
airplane mode you can see that you bounce into `disconnected` and then
back to `connected`, so I don't think we'd want to fail the call as long
as WebRTC considers it "recoverable".
// FREEBIE
We do this by manually managing the RTCAudioSession.
Unfortunately to do this we have to include a couple of RTC headers not
exported by the default build of WebRTC.framework (see: Libraries/WebRTC)
// FREEBIE
This makes sense as PeerConnectionClient is our interface to WebRTC
- Makes it easier to test PeerConnectionClient and CallService
- Allows us to shrink CallService class a bit (it's huge)
// FREEBIE