If CallKit privacy is enabled, we'll always use the system default
ringer.
If CallKit privacy is *not* enabled we'll use any ringtone specified in
the for that contact in the address book, else fall back to the default
// FREEBIE
- sync speakerphone state manipulated from system call screen
- Revert audio session after call failure, ensures media plays out of
speaker after placing a failing call.
- Replace notification with delegate pattern since we're already using
delegate pattern here.
- Fixes voiceover accessibility after voice memo
- Avoid audio blip after pressing hangup
- Rename CallAudioSession -> OWSAudioSession
Going to start using it for other non-call things since we want to
gather all our audio session concerns.
- Resume background audio when done playing video
- Extract OWSVideoPlayer which ensures audio is in proper state before
playback
- Move recording session logic to shared OWSAudioSession
- Deactivate audio session when complete
// 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
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
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
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
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
This is an effort to better define boundaries and simplify
relationships.
This also fixes a theoretical problem where CallKit was showing the in-app
call screen before the call was successfully answered, now we wait until
the action is fulfilled.
// FREEBIE
In the process, extracted the CallDelegate to allow the
CAllViewController to observe useful call state properties (call.state
and call.isMuted)
// FREEBIE