The topic is based on an accidental discovery of mine regarding the seemingly persistent inability of the desktop counterpart of FaceTime to pass the connectivity wall of the mobile one. When the call is initiated Console, among others, contains the entry
The entry pinpoints the source of the misbehaviour which is those settings of the iOS device that are responsible for power management, namely in the section Do Not Disturb: the settings in question are Silence repeated calls from the same person, Silence calls when the screen is locked. When the iOS device goes into sleep mode its screen locks automatically after some preprogrammed amount of time. If you go to Settings-->Do Not Disturb-->Silence you'll see that Apple left only 2 options to choose from: "Always" and "When the screen is locked". There's no "Never". To figure out how to deal with that and as a partial solution you have to disable Auto-lock which is possible only if you turn off Low Power Mode and set Auto-lock to Never. However, when your iPhone enters standby mode it still locks itself.
With iPhone locked when FT from a Mavericks machine tries to reach its mobile counterpart, it simply can't because it's unable to "create the power assertion" - something like the caffeinate (10.9 and later) or pmset (every macOS) command utilities do on the desktop: with them, you can wake the Mac, turn on/off the display, system or disk at any designated time - "create a power assertion". In the case of FaceTime, your Mavericks machine should be capable of performing the same action but it isn't. If you unlock your iPhone and immediately call then the call reaches it. If it locks back the call is dropped.
NB. They fixed the bug in newer versions, and as of High Sierra and Mojave - 2 macOSes I've used personally - calls from the desktop FaceTime are able to break through the locked state of the iPhone.
The problematic settings
NB. It seems iOS 13 presented a new case where incompatibility between it and Mavericks introduced new connectivity shortcomings. The assumptions from above pertained to iOS 12 that I still use and may not apply to the full extent in regard to iOS 13.
NB Video calls between Mavericks and iOS as new as version 12 halt when the recipient answers the call on iOS, audio calls produce clearly audible echo and artificial background noise which are unfixable.
Unable to create the power assertion for "ActiveFaceTimeConferenceAssertion"
The entry pinpoints the source of the misbehaviour which is those settings of the iOS device that are responsible for power management, namely in the section Do Not Disturb: the settings in question are Silence repeated calls from the same person, Silence calls when the screen is locked. When the iOS device goes into sleep mode its screen locks automatically after some preprogrammed amount of time. If you go to Settings-->Do Not Disturb-->Silence you'll see that Apple left only 2 options to choose from: "Always" and "When the screen is locked". There's no "Never". To figure out how to deal with that and as a partial solution you have to disable Auto-lock which is possible only if you turn off Low Power Mode and set Auto-lock to Never. However, when your iPhone enters standby mode it still locks itself.
With iPhone locked when FT from a Mavericks machine tries to reach its mobile counterpart, it simply can't because it's unable to "create the power assertion" - something like the caffeinate (10.9 and later) or pmset (every macOS) command utilities do on the desktop: with them, you can wake the Mac, turn on/off the display, system or disk at any designated time - "create a power assertion". In the case of FaceTime, your Mavericks machine should be capable of performing the same action but it isn't. If you unlock your iPhone and immediately call then the call reaches it. If it locks back the call is dropped.
NB. They fixed the bug in newer versions, and as of High Sierra and Mojave - 2 macOSes I've used personally - calls from the desktop FaceTime are able to break through the locked state of the iPhone.
The problematic settings
NB. It seems iOS 13 presented a new case where incompatibility between it and Mavericks introduced new connectivity shortcomings. The assumptions from above pertained to iOS 12 that I still use and may not apply to the full extent in regard to iOS 13.
NB Video calls between Mavericks and iOS as new as version 12 halt when the recipient answers the call on iOS, audio calls produce clearly audible echo and artificial background noise which are unfixable.
Last edited: