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

简介

本文档介绍如何对APNS“400错误请求”错误进行故障排除；Cisco bug IDCSCvi01660中记录的已知问题。

先决条件

要求

Cisco 建议您了解以下主题：

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

使用的组件

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

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

背景信息

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

要通过Cisco Cloud进行身份验证，您的Cisco Communications Manager Server会在自注册过程中生成令牌。如果您收到“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

故障排除

设置下一个日志以调试并使用实时监控工具收集日志：

思科统一通信管理器:

思科推送通知服务

思科管理代理服务

Cisco Unified Communications Manager IM and Presence:

思科XCP配置管理器

思科XCP路由器

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

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 

您会看到Cisco 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 

这是已知的Cisco Bug ID CSCvi01660。

解决方案

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

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

步骤 1：

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

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

此外，在实验室环境中运行命令“run 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：

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

思科统一通信管理器::

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

Cisco Unified Communications Manager IM and Presence:

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

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

验证

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