52134 - Invalid APNs device token

[syrakozz]

i put a certificate for production in twilio but im not getting the push the error in logs is >>52134 - Invalid APNs device token am i doing it wrong ?

[bobiechen-twilio]

Hi @syrakozz

Thanks for creating the issue here. Could you please describe more about your environment?

• What is the environment config of the Push Credential SID (sandbox or non-sandbox)?
• Is the app installed from Xcode debugger or did you export the app for Ad Hoc or enterprise or store submission?

Also it would be great if you can update the error details like you did in this issue so other users who are getting the same errors can reference.

Thanks. -bobie

[syrakozz]

non-sandbox store submission (testflight)

[syrakozz]

@bchen-twilio can you plz provide a link to a step by step guide for production cert

[syrakozz]

we are using twiml

[bobiechen-twilio]

Hi @syrakozz

For Push Credential for the production environment:

• The VoIP cert is the same as the one used for development environment
• The Push Credential SID is different from the one used for the dev environment and should be created separately. Same cert and secret are used but this time without checking the sandbox option in the Twilio console
• In your production application, specify necessary parameters so that the Access Token generated from your server embeds the production Push Credential SID

Hope this helps. -bobie

[ariveraati]

We are getting the same error in our app. In our case this is an enterprise distribution / production app. Across all our devices we see the same error triggered in the Twilio debugger console. Also, when the app has been killed, an incoming call is not triggering the app to re-open. I assume it is related to this error. Please advise.

Update Recreated the cert and push credential from scratch and we no longer see that error. We do see "Empty Credential" but I think that is due to old sessions holding onto the previous credential. We'll try again in a few hours.

[bobiechen-twilio]

Hi @syrakozz, did you manage to receive push notifications for your production app?

Hi @ariveraati, glad to know that the notifications work with the new cert and push credential. Is the app able to provide the user incoming call notification in the background with the new certificate?

[ariveraati]

@bchen-twilio Thanks for the quick reply. If the app is just backgrounded, the call comes in just fine. If the app is killed, we don't see the call. However, looking at the console log of the device, we see that it is receiving the VOIP push and trying to resume the app. It just doesn't succeed for some reason. We are still digging. I'll let you know if we find anything else strange in the logs. Thanks!

[ariveraati]

@bchen-twilio the behavior we are seeing is basically what you described here: https://github.com/twilio/voice-quickstart-swift/pull/201 but the ObjC code we are using seems to incorporate your fix. The odd thing is that this only happens when the app is terminated. It works just fine when its in the background.

[ariveraati]

@bchen-twilio sorry for the multiple messages here, but we do see that the push notification handler is being fired. When we manually open our app after an incoming push occurred while it was terminated, the callkit handler fires/continues and we briefly see the call pop up and immediately disconnect and disappear (even though the call occurred minutes ago). Its almost as though its queued and when the app is launched manually, it tries to execute the callkit handler.

[bobiechen-twilio]

Thanks for the update @ariveraati. The observation you described matches what we also observed while working on the issue. I'll investigate with the sample apps and keep you updated.

-bobie

[bobiechen-twilio]

Hi @ariveraati,

I've tried the quickstart (regular, not the CallKit one) and observed the same behavior when the app is terminated. The root cause is the same as the one we found last time - the app goes into background-suspended mode once the incoming push completion handler is fulfilled, before the user-notification can pop up. Not sure this is only happening when the app is terminated but we will update the sample code.

While we are working on it, you can also make the change to this block:

if ([[UIApplication sharedApplication] applicationState] != UIApplicationStateActive) {
    UNUserNotificationCenter *center = [UNUserNotificationCenter currentNotificationCenter];
    UNMutableNotificationContent *content = [UNMutableNotificationContent new];
    content.title = @"Incoming Call";
    content.body = [NSString stringWithFormat:@"Call Invite from %@", callInvite.from];
    content.sound = [UNNotificationSound defaultSound];

    UNNotificationRequest *request = [UNNotificationRequest requestWithIdentifier:@"VoiceLocaNotification"
                                                                              content:content
                                                                              trigger:nil];

    [center addNotificationRequest:request withCompletionHandler:^(NSError *error) {
        if (error) {
            NSLog(@"Failed to add notification request: %@", error);
        }
        // Fulfill the completion handler after the user-notification is done
        [self incomingPushHandled];
    }];
} else {
    // Fulfill immediately since the app is active and no need to show the user-notification
    [self incomingPushHandled];
}

-bobie

[ariveraati]

@bchen-twilio Thanks for the information. I want to make sure I was clear on the issue we are seeing. It's specific to CallKit. When the app is killed, we don't see the CallKit popup at all. But then when we open the app manually, we see CallKit show up very briefly and then disappear.

The code block you posted above seems to only deal with a notification to the user, not CallKit specifically. Is that right? Do you think this will somehow solve our specific issue?

[bobiechen-twilio]

Thanks for the additional info @ariveraati. I tried both the regular and the CallKit sample apps but was only able to reproduce the issue on the regular one that's why I was assuming it was only happening in the regular quickstart. However the issue you described still sounds related to the background-suspended issue.

Could you please share how and where the incoming-push completion (if the app is using the pushRegistry:didReceiveIncomingPushWithPayload:forType:withCompletionHandler: method) is fulfilled in the application? The CallKit quickstart waits until the call has been answered before calling the completion so that the app won't go into the suspended mode and can show the incoming call via the System Call app.

-bobie

[ariveraati]

@bchen-twilio that method is identical to your example app.

I also looked for usages of the same call to incomingPushHandled and it seems to follow your example.

You can see the full implementation here: https://github.com/ariveraati/cordova-plugin-twiliovoicesdk/blob/master/src/ios/TwilioVoicePlugin.m

[bobiechen-twilio]

Thanks @ariveraati. While I am not the expert of the Cordova native plug-in, do you think this is similar to this discussion?

-bobie

[ariveraati]

@bchen-twilio it could be specific to Cordova. I took a look at that thread and it seems as though they are seeing something related to JS callbacks, but that isn't really our problem. Our problem is specific to the CallKit handling which occurs within the native code (not cordova). We'll keep digging! Thanks for the help so far.

[bobiechen-twilio]

Sure thing! Thanks for reporting the issue and sharing information since this could potentially help other SDK users using JS plug-ins. We would love to hear any new findings from you and definitely happy to assist.

-bobie