VoIP Push is not working for audio video calling

[kushal211]

New Issue Checklist

• [x] I have read the Documentation
• [x] I have searched for a similar issue in the project and found none

Environment details

Info	Value
iOS Version	e.g. 12.1.4
Quickblox iOS SDK version	e.g. 2.17.4
QuickbloxWebRTC SDK version	e.g. 2.7.4
Xcode Version	e.g. Xcode 10.3
Repro with our demo sample	e.g. does it happen with our demo sample? - YES, Tried sample-videochat-webrtc-swift and it is not working

Did this work before? Yes, It was working before, but all of sudden it is stops working.

Expected behavior I tried to send push notification from the admin dashboard but it is failed each time. The user is subscribed to the VoIP push successfully and it is showing in the list as well.

When VoIP push is sent from the admin panel, it should send the push to the subscribed devices without any error.

Actual behavior The push should be delivered.

Logs here is the error log for the push notification I downloaded from admin panel: You can find the log from the attachment as well. 30660269_log.txt

{
  "notification": {
    "id": 24616353,
    "badge": null,
    "device_token": "667fb32719fb1707758b27e93a8ab82640b5b02c6b63d3fbe0216d95c82e6fbd",
    "sound": "default",
    "alert": "4",
    "data": {
      "headers": {
        "apns-topic": "com.sample.voip",
        "apns-push-type": "alert"
      }
    },
    "expiry": 86400,
    "delivered": false,
    "delivered_at": null,
    "failed": true,
    "failed_at": "2019-09-20T04:55:21+00:00",
    "fail_after": "2019-09-20T05:55:20+00:00",
    "retries": 0,
    "error_code": 400,
    "error_description": "InvalidPushType",
    "deliver_after": null,
    "alert_is_json": null,
    "app_id": 43070,
    "collapse_key": null,
    "delay_while_idle": null,
    "registration_ids": null,
    "uri": null,
    "priority": null,
    "url_args": null,
    "category": null,
    "content_available": false,
    "mutable_content": false,
    "notification": null,
    "type": "Rpush::Client::Redis::Apns::Notification",
    "event_id": 30660269,
    "event_date": "2019-09-20T04:55:20+00:00"
  },
  "log": [
    {
      "device_token": "667fb32719fb1707758b27e93a8ab82640b5b02c6b63d3fbe0216d95c82e6fbd",
      "delivered_at": null,
      "failed_at": "2019-09-20T04:55:21+00:00",
      "error_code": 400,
      "error_description": "InvalidPushType"
    }
  ]
}

Please use the following template for logs:

To enable full logs use the following code:

[QBSettings setLogLevel:QBLogLevelDebug];
[QBSettings enableXMPPLogging];

Title for logs

```logos // Your logs here ```

Steps to reproduce the behavior Just try to run the sample project sample-videochat-webrtc-swift and check if they receive the Push or not. I've tried with following the Quickblox SDK version - 2.17.1, 2.17.4 with Xcode 10.3 and Xcode 11 GM Seed 1.

Any others comments I have also tried creating the certificate again and uploading them to the admin panel with and without a password. But it does not make any difference. Please note that the Normal Push notification is working fine but the only VoIP push is not working.

[dansinclair25]

I'm seeing this issue too. It's because Quickblox have added the apns-push-type header to the APNS request but Apple are rejecting it for some reason (even though, according to Apple's docs, it should be working).

Surprised to see QB haven't reverted this change though already - was it tested before it was pushed to production?

[Rich2k]

Apple's documentation currently states that apns-push-type is required for delivering to all devices running iOS 13 and is silently ignore for < iOS 12, however it appears that Apple is NOT currently enforcing this. See https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/sending_notification_requests_to_apns

I have tried non-VoIP notifications today with both the push type missing AND included and they both get delivered successfully to iOS 13 devices.

However the QB VoIP notifications are failing stating that apns-push-type of alert is not allowed (so I'm wondering if apns-push-type is not permissable specifically on VoIP notifications or VoIP push notifications need to use a third, undocumented, type of apns-push-type other than alert and background)

[kushal211]

I have tried in both iOS 12.4 and iOS 13 (Xcode 10.3 and Xcode 11), The non-VoIP notifications are working without any problem in both iOS versions, but the VoIP push is not working at all.

An interesting fact is that their sample project (sample-videochat-webrtc-swift) is not even able to work for VoIP push notification.

Apparently I've tried with another third-party platform Pusher for VoIP push and luckily it worked with the VoIP Push certificate.

Urgently looking for a solution on this.

[dansinclair25]

@kushal211 you tried a VoIP push with NWPusher with the apns-push-type key added? Every time I've tried sending it locally with that key in the header, it fails.

[kushal211]

@dansinclair25 , I've tried without apns-push-type to NWPusher and it worked for iOS 12.4. But to test this I've to select specific VoIP Certificate and not the Universal (Sandbox & Production & VoIP) SSL certificate.

[Rich2k]

@kushal211 Pusher doesn't appear to be sending the apns-push-type at all yet, I'm in contact, separately, with their support team about supporting this

[kushal211]

@Rich2k , Agree with you, doesn't seems like they are sending. And appreciate your support. 😃👍🏼 Please update here if you get any further update.

PS. Here's the NWPusher SS I tried with. It delievered the VoIP push on both iOS 12 and 13.

[kushal211]

Hi @Rich2k , Did you find any solution/workaround for this push issue?

[ghost]

Hello @Rich2k @kushal211 @dansinclair25

Thank you for contacting QuickBlox support.

Even you try sending push from the admin panel and it is showing as a failed. =>>Make sure that you have chosen the right environment. Its “Testing” for the debug build and “Live” for the release build.

[ghost]

Hello @kushal211

The status of the ticket changed to "Closed", because you haven't provided me with an answer. You can reopen this ticket, if you would like to continue the discussion of the reported issue.