Though it should be fine, reloading the callUIAdapter is a bit heavy
handed. And the current implementation is prone to being broken, since
we sometimes forget not to treat callUIAdapter as a singleton.
Longer term we can find a way to either: make callUIAdapter a true
singleton or possibly make callUIAdapter a private member of something
which *is* a true singleton.
Since we only *need* it to be reloaded the one time the migration runs
(or when a user changes settings which should be rare) it makes sense to
remove it from the happy path.
// FREEBIE
callUIAdapter is not a singleton (for better or for worse)
No one should hold a reference directly to it, but rather via the
CallService, which is a singleton
Wait a bit longer for initial call screen before terminating. Especially
first call can hit this limit.
When call *does* take too long to show, terminate properly to ensure
we're not left with a phantom call
// FREEBIE
Don't obscure message text on smaller form factors
Also, disable overzealous assert with non-callkit adapters. The adapter
is not a singleton, it gets rebuilt whenever call related privacy
settings are triggered.
// FREEBIE
We've long allowed users to configure what shows up in message
notifications:
- name: content (by default)
- just name (no content)
- generic notification (no name nor content)
Now we're dual purposing that setting to apply to calls. If someone
doesn't want to show names in the message notifications, presumably also
don't want that name showing up in the call log.
Also, since the earlier CallKit/iCloud issues had been addressed before
iOS11, we upgrade all iOS11 users to the more intuitive CallKit
interface.
Also: introduce "use system call logs" toggle when available. It will be
enabled by default, but we disable it for legacy users who'd explicitly
opted *out* of CallKit.
// FREEBIE
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
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
This affects iOS 8, 9, and to a lesser degree iOS10.
On iOS11, presenting an alert causes the keyboard/inputAccessoryView to
temporarily dismiss.
// 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
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
When awakened by a voip push, we get some arbitrary amount of background
time to connect the call (in practice this is ~30s) before the app is
suspended.
Though we were properly terminating the call upon being suspended, we
were not notifying the user that they had missed a call.
// FREEBIE
From: https://developer.apple.com/library/content/qa/qa1754/_index.html
Q: Can you explain the difference between calling the AVAudioSession method overrideOutputAudioPort: with the value AVAudioSessionPortOverrideSpeaker and using the category option AVAudioSessionCategoryOptionDefaultToSpeaker with setCategory:withOptions:error:.
A: The difference is that setting the AVAudioSessionPortOverride by calling overrideOutputAudioPort: is more transient than using the category option AVAudioSessionCategoryOptionDefaultToSpeaker.
Important: The use of both AVAudioSessionPortOverrideSpeaker and AVAudioSessionCategoryOptionDefaultToSpeaker are only applicable to the AVAudioSessionCategoryPlayAndRecord category.
Calling overrideOutputAudioPort: and setting the AVAudioSessionPortOverride to AVAudioSessionPortOverrideSpeaker is a way of temporarily overriding the output to play to the speaker. Any route change or interruption will cause the audio to be routed back to its normal route, following the last-in wins rule. Think of using overrideOutputAudioPort: in terms of what you might use to implement a Speakerphone button where you want to be able to toggle between the speaker (AVAudioSessionPortOverrideSpeaker) and the normal output route (AVAudioSessionPortOverrideNone).
Note: This property is intended to allow 3rd party applications to mimic the behavior of a Speakerphone button and therefore may change the input route as well as output route. For example, setting the AVAudioSessionPortOverride to AVAudioSessionPortOverrideSpeaker while a headset is plugged in will cause the route to change to built-in mic / built-in speaker.
// FREEBIE
// FREEBIE
TODO
NEED
-[ ] icon in route picker
-[ ] commit cleanup
NICE
-[ ] present action sheet automatically when making outgoing bluetooth call
-[ ] left align icons
-[ ] audio is paused when switching between video mode (maybe existing behavior, not sure)
-[ ] Copy: iPhone/iPad/iPod instead of "iPhone Microphone"
DONE
-[x] remove "receiver" from options while in video mode
-[x] show available audio routes
-[x] select available audio routes
-[x] notification if availabe inputs change so we can update call screen
mid call with available BT route
-[x] include speakerphone in choices
-[x] Enabled button shows active speakerphone. Should still show
bluetooth picker.
-[x] toggle back and forth between audio devices
-[x] hide audio route button in video mode if no BT available
-[x] Fixed: When on speakerphone - switching to video mode goes back to bluetooth.
-[x] Fixed: When switching to video w/ bluetooth device connected there is no
audio picker.
-[x] respect speakerphone/BT selection when in or toggling to/from video
-[x] do not hide audio route button when in video mode and bluetooth
connected
-[x] Show which is currently selected audio route
-[x] switching to speakerphone no longer works
-[x] switching *back* to bluetooth no longer works
-[x] add proper bluetooth button for audio calls
-[x] add proper bluetooth button for video calls
This ensures message ordering for clients that can't handle out of order
call messages (legacy iOS and Android).
Even when we revert the previous commit, to send ICE Updates sooner,
we'll want to keep this (until we're confident all clients can receive
out of order call messages)
// FREEBIE
That change makes it more likely that the remote client will receive an
ICE update before their peer connection client is set.
We want to ship the robustness fix (waitForPeerConnection in
handleRemoteAddedIceCandidate) before we have the caller start sending
ICE updates immediately, in a future release.
At that time, we can simply revert this commit.
// FREEBIE
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