简介
本文档介绍如何对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:
这些服务必须在数小时后重新启动,以避免任何服务影响。
验证
现在,在包括IMP的所有节点上再次运行“run sql select * from machineaccountdetails”,并立即验证您是否具有我的刷新令牌。