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
...in response to CR, move the AudioService off of the CallViewController
Adopt multiple observer pattern vs. a singular delegate. Doing so
required implementing some machinery to address the ARC (see:
Weak.swift)
// FREEBIE
Implement speakerphone toggle directly. Previously we were using
AppAudioManager for several things, but this is that last lingering bit.
Much of the AppAudioManager code is based on RedPhone calling, so by
removing the dependency we pave the way to throw that code away.
// FREEBIE
8 Cases considered:
(Silent Switch toggled vs. Silent Switch not-toggled)
x (App in Foreground vs. App in Background)
x (CallKit vs. NonCallKit)
CallKit already does the "right thing"
// FREEBIE
There isn't much the user can do in response to it, and the user will
get a subsequent "new message" notification when the fallback push
triggers.
// FREEBIE
Because logging-preference was previously stored on the storageManager
this meant we couldn't possible log anything related to the init'ing the
storage manager.
TODO: migrate old logging preference to use the new NSUserDefaults
setting
// FREEBIE
Most likely this would be because the user hasn't unlocked their device
since last restart.
This behavior existed once before, but the startup ordering is pretty
delicate. So, we're now redundantly checking in SSK in case this
delicate startup logic gets mis-ordered again.
Also fixed the AppDelegate method to check for the proper
applicationState, since it will never be "active" in didFinishLaunching.
fixes https://github.com/WhisperSystems/Signal-iOS/issues/1627
// 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