排除​APNS "；400错误请求"；错误

简介

本文档介绍如何排除APNS“400 bad request”错误；此已知问题记录在Cisco bug IDCSCvi01660中。

先决条件

要求

Cisco 建议您了解以下主题：

• Apple Push Notifications 配置.
• Apple Push Notifications 功能。

使用的组件

本文档不限于特定的硬件和软件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

当集群启用推送通知时，思科统一通信管理器和IM and Presence Service使用Apple或Google云的推送通知服务将推送通知发送到在iOS或Android设备上运行的兼容Cisco Jabber或Webex客户端。推送通知(Push Notifications)让您的系统与客户端通信，即使在客户端进入后台模式（也称为挂起模式）后也是如此。如果没有推送通知，系统可能无法向进入后台模式的客户端发送呼叫或消息。

要使用Cisco Cloud进行身份验证，Cisco Communications Manager服务器会在自行激活过程中生成令牌。如果您收到“400 bad request”消息，则表示您对Push Notifications服务的计算机访问令牌已过期，您需要根据文档手动更新访问令牌：

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/push_notifications/cucm_b_push-notifications-deployment-guide/cucm_b_push-notifications-deployment-guide_chapter_01.html?bookSearch=true

故障排除

将后续日志设置为调试，并使用Real Time Monitoring Tool收集日志：

Cisco Unified Communications Manager ：

思科推送通知服务

思科管理代理服务

Cisco Unified Communications Manager IM and Presence：

思科XCP配置管理器

Cisco XCP路由器

在思科推送通知服务日志中，您可以看到CUCM收到多个 400个回复 在获取导致APNS失败的令牌时，计数器不会增加：

2024-07-16 15:09:50,514 DEBUG [Timer-144] ccmpns.CCMPNServer (CCMPNServer.java:306) - fetchAndStoreAccessToken() Response received : 400  2024-07-16 15:19:51,007 DEBUG [Timer-145] ccmpns.CCMPNServer (CCMPNServer.java:306) - fetchAndStoreAccessToken() Response received : 400  2024-07-16 15:29:51,605 DEBUG [Timer-146] ccmpns.CCMPNServer (CCMPNServer.java:306) - fetchAndStoreAccessToken() Response received : 400  2024-07-16 15:39:52,096 DEBUG [Timer-147] ccmpns.CCMPNServer (CCMPNServer.java:306) - fetchAndStoreAccessToken() Response received : 400  2024-07-16 15:49:52,565 DEBUG [Timer-148] ccmpns.CCMPNServer (CCMPNServer.java:306) - fetchAndStoreAccessToken() Response received : 400  2024-07-16 15:59:53,032 DEBUG [Timer-149] ccmpns.CCMPNServer (CCMPNServer.java:306) - fetchAndStoreAccessToken() Response received : 400 

您可以看到在发出呼叫时思科XCP路由器日志上出现无效响应：

2024-07-16 17:21:43,464 DEBUG [Timer-1382] xmlframework.XCPConfigMgr - FetchAndStoreAccessToken: Calling createAccessToken() with granttype:refresh_token, refreshToken:MTc2YzFhN2YtMDA1Ny00MTVlLWJGZmMjcwYTU3MjY1NGI1NzItZmE0, accessTokenURL proxyUsernamenull  2024-07-16 17:21:43,468 INFO  [Timer-1382] utilities.CloudOnboarding - TRACKING ID:::::::FOS_e8e8ee93-818f-4fe5-8a23-6b08a879b91b  2024-07-16 17:21:43,790 ERROR [Timer-1382] utilities.TomcatTrustManager - checkServerTrusted:entered   2024-07-16 17:21:43,791 ERROR [Timer-1382] utilities.TomcatTrustManager - checkServerTrusted:entered 2  2024-07-16 17:21:43,958 DEBUG [Timer-1382] xmlframework.XCPConfigMgr - XCPConfigMgr:Inside responseStatus()  2024-07-16 17:21:43,958 ERROR [Timer-1382] xmlframework.XCPConfigMgr - 400 Bad Request: invalid_request, unsupported_grant_type, invalid_client, invalid_refresh_token, tokenlimit_reached  2019-07-16 17:21:43,958 DEBUG [Timer-1382] xmlframework.XCPConfigMgr - XCPConfigMgr:FetchAndStoreAccessToken: Inside Finally Block 

这是一个已知思科漏洞ID CSCvi01660。

解决方案

构建实验室系统并将实验室中的刷新令牌更新到生产系统。

部署实验室系统后，请执行以下步骤：

步骤 1：

在Call Manager发布服务器上，打开CLI会话并运行命令“run sql select * from machineaccountdetails”并将所有输出保存在.txt文件中：

保存所有输出后，请特别注意Call Manager pkid，例如，我们的实验室环境为“e40c24c0-cd4c-4256”。

         

此外，在实验室环境中运行“运行sql select * from machineaccountdetails”命令，并将所有输出保存在.txt文件中。

请特别注意实验室环境中的refreshtoken，因为这是我们用来替换生产环境中无效令牌的有效令牌。在我们的实验室环境中，OGYyZGI2MWMtNjUwYy00Y2FiLThh”。

步骤 2：

我们需要用有效的实验室令牌替换您当前不工作的刷新令牌。

保存生产包之后，请在生产Call Manager发布服务器中运行此sql查询： 

运行sql update machineaccountdetails set refreshtoken='here goes the valid refresh token of your laboratory environment' where pkid='here goes your production pkid'。 

前面的sql查询使用实验室环境中的工作令牌更改非工作令牌。

步骤 3：

使用实验室刷新令牌更新计算机帐户详细信息后， 请重新启动这些服务：

Cisco Unified Communications Manager ::

• 思科管理代理服务(CMAS)
• 思科推送通知服务(CCMPNS)
• Tomcat

Cisco Unified Communications Manager IM and Presence：

• XCP配置管理器 
• XCP路由器
• Tomcat

这些服务必须在数小时后重新启动，以避免任何服务影响。

验证

现在再次对所有节点（包括IMP）运行“run sql select * from machineaccountdetails”，并验证您现在是否具有我的刷新令牌。