iOS PushKit integration

[mixinnetwork]

iOS PushKit integration

[cedricfung]

Why PushKit for WEBRTC_AUDIO_CANCEL?

[wuyuehyang]

Why PushKit for WEBRTC_AUDIO_CANCEL?

Stop receiver from ringing after the caller choose to cancel

[cedricfung]

After the receiver received OFFER PushKit, they should have connected to WebSocket. So any further notifications should use the WebSocket connection. If in rare condition, the WebSocket connection is lost during ringing, we should always have a timeout to dismiss the ringing interface.

[cedricfung]

Ideally all our operations are done after WebSocket connected, so I don't think SDP is needed in the notification payload.

[jadeydi]

Does MessageCategoryKrakenInvite need pushkit?

[crossle]

Does MessageCategoryKrakenInvite need pushkit?

YES.

[wuyuehyang]

According to console log:
Apps receving VoIP pushes must post an incoming call (via CallKit or IncomingCallNotifications) in the same run loop as pushRegistry:didReceiveIncomingPushWithPayload:forType:[withCompletionHandler:] without delay.

Exchanging WebRTC descriptions through WebSocket connection seems to be incapable of satisfying PushKit restrictions in iOS 13. To report a new incoming call and implement functionality in system calling interface (e.g. decline by callee), the offer message's id, caller's user_id and caller's fullname, at least these 3 values must be provided in the push payload. Furthermore, it would be easier for front-end developing if full BlazeMessageData along with caller's User structure could be provided in the payload.

[cedricfung]

When user accepts or declines the call, should the app need to connect the WebSocket and send blaze message?

[wuyuehyang]

When user accepts or declines the call, should the app need to connect the WebSocket and send blaze message?

Yes, it can be performed with VoIP background mode.

[cedricfung]

I think I get it, whenever connect the WebSocket, the app need to wait all the pending messages until the OFFER message to get the SDP info, until then the app can't send any messages to answer the call.

If the SDP info included in the PushKit payload, then the app would be able to send ANSWER or DECLINE message as soon as WebSocket connected, no need to wait all pending messages to get the SDP.

[wuyuehyang]

The main point of new VoIP restriction is reporting incoming call to CallKit when PushKit notification is received, with no delay. That requires some key information(two ids and a name) to be provided in the payload.
As long as the restriction is satisfied, app won't be complaining about it, the underlying data exchange can be performed by any means. A full BlazeMessageData is only for easier implementation.

[cedricfung]

Maybe it won't help a lot for speeding up the WebRTC connection just with the SDP in payload. Because after callee ANSWER with the SDP, it still needs to wait all pending messages to receive further ICE messages to establish the connection. Then it's better to not including those messages in PushKit payload.

That said, we should include the full caller view in PushKit payload, and I think the message id is already included?

Otherwise, if it was possible to speed up the PeerConnection establishment, without waiting pending messages, we could include SDP in Pushkit payload.

@crossle

[crossle]

If you didn’t put caller information in your notification’s payload, call the reportCall(with:updated:) method of your app's provider object to update the calling interface. You can call that method at any time to update calls. For example, call it after your app fetches updated caller information from your VoIP server.

https://developer.apple.com/documentation/pushkit/responding_to_voip_notifications_from_pushkit

[cedricfung]

It's OK to include caller's information to present the CallKit UI instantly for better user experience.

The question is whether to include SDP, would it help with faster PeerConnection.

[wuyuehyang]

If you didn’t put caller information in your notification’s payload, call the reportCall(with:updated:) method of your app's provider object to update the calling interface. You can call that method at any time to update calls. For example, call it after your app fetches updated caller information from your VoIP server.

It's OK to update username after, but the call's UUID and caller's user_id is required for unique constraint of a call.

[over140]

#503