consolidated feature-disable logic for incoming/outgoing calls to make
it easier to document, and less likely to break when we *do* implement
CallHolding
// FREEBIE
- Alice calls Bob on Signal and they start talking
- Charlie calls Alice on Not-Signal.
- Alice chooses to "Hold & Accept" putting Bob on Hold while the call with
Charlie connects.
- If Alice ends the call with Charlie, we're back in Signal-iOS and
talking to Bob, no problem.
- However, if, before ending the call with Charlie, Alice tries to swap
*back* to bob, bob won't hear any audio in the callkit screen. Alice
has to switch back to the Signal screen before the audio is transmitted.
// FREEBIE
Marking Signal-Call as started, changes the incoming call screen for
subsequent calls to show "Accept & End", "Send to VoiceMail" and "Accept
& Hold" instead of just "Accept" & "Decline"
Though - we don't support Holding. What we really want to see is just
"Accept & End" and "Decline | Send to Voicemail"
// FREEBIE
This slows the UI, but only for people who have locally opted into
WebRTC calls, and the alternative is that users are likely to have stale
settings the first time a pair of people opt-in.
// 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
The removed code was from an older eon. CallService shouldn't be touched
except via the CallUIAdapter since only there is the omnipresent
distinction between CallKit vs. NonCallKit made.
i.e. when the RTCAudioSession get's started depends on the
CallUIAdaptee.
// FREEBIE
TODO: this is going to be weird when two parties are *just* enabling
webrtc for the first time. We might want to do something as drastic as
refetch contact information before completing the call.
// FREEBIE
coordinate SignalProtocol encryption/decryption on a single serial
queue. Previously message sending encrypted on the sending thread, while
message receiving decrypted on the main thread.
// FREEBIE
