It's always good to give the system the most information you know. Generally, when systems ask you for a reason for something, they have a reason to do it (pun intended).
I found this in Apple's official documentation:
Many things can go wrong when connecting a VoIP call, and CallKit makes it easy to handle problems when they occur.
- If the person who initiated the call hangs up, use the network connection between your app and server to notify the app. In your app, call the
reportCall(with:endedAt:reason:)
method of its CXProvider
object, specifying CXCallEndedReason.remoteEnded
as the reason for the end of the call. If the incoming call interface is onscreen, CallKit updates the interface to reflect the end of the call, and dismisses the interface.
- If the recipient of a call answers before the app establishes a connection to your server, don't fulfill the
CXAnswerCallAction
object sent to the provider(_:perform:)
method of your delegate immediately. Instead, wait until you establish a connection and then fulfill the object. While it waits for your app to fulfill the request, the incoming call interface lets the user know that the call is connecting, but not yet ready.
- If your app fails to establish a connection to your server, call the
reportCall(with:endedAt:reason:)
method with the CXCallEndedReason.failed
option. If the incoming call interface is currently onscreen, the system updates it to indicate a failed call.
And according to this quickstart in AT&T's developer documentation:
Inform CallKit about the failed incoming call.
[...]
Failure to inform CallKit a couple of times and iOS 13 will block app from receiving VoIP push.
So to your question:
Is this something I can reasonably ignore?
I would answer no.