Now that SN changes do not block incoming messages, the caller does not
need to enqueue outgoing ICE updates.
However this introduces the possibility that the call recipient could
recieve an ICE update before their peerConnectionClient is set up - so
now we ensure that call service waits for it's peerConnectionClient
before processing incoming ICE updates.
// FREEBIE
In theory this shouldn't make a difference, since we're not playing the
ringer twice, but in practice I fail to here ringer audio 50% of the
time (in DEBUG builds) while app is in the foreground.
// FREEBIE
dropped into a different thread when the call is over.
e.g. chatting with Alice, but Bob calls. When I end the call with Bob It
would be too easy to fire off a message assuming it's going to Bob.
// FREEBIE
* explicit optional usage in strings
* remove some unused StringUtil code
* swiftlint affected files
* more concise optional casting (and avoid a `!`)
Compiler warnings: 343 -> 318
(Actually most of these are in external libs, but 115 remain in Signal/SSK)
// FREEBIE
* copy tweaks
* use "settings" instead of "privacy settings" for button text
* include comments in NSLocalizedString param so they can be extracted with genstrings
* style dismiss action as "cancel"
// 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
More fallout from the outbound call timeout which was causing all
CallKit calls not promptly answered to show "Call Failed"
Inserting the timeout exacerbated an existing issue: We can't wait for
long before choosing to fulfill/fail an action without CallKit falling
over and assuming the call failed.
We don't actually need to consider the case where we "fail to initiate"
the outgoing call. Instead we say it started "successfully, and if there
is an error, the existing promise error handling will fail the call at
that time.
// FREEBIE
- Previously only incoming calls had their timeout promise fulfilled
- Previously we'd stop the timeout once ringing started, but we
should continue the timeout clock until the users are speaking.
// FREEBIE
Previous logic assumed "VoiceChat" mode, but when the ringer goes off,
we set "SoloAmbient" which is incompatible with that mode, causing
assertion failure.
// FREEBIE
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
...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