排除​APNS "；400錯誤請求"；錯誤

簡介

本文檔介紹如何對APNS「400錯誤請求」錯誤進行故障排除；Cisco bug IDCSCvi01660中說明了這一問題。

必要條件

需求

思科建議您瞭解以下主題：

• Apple Push Notifications 組態.
• Apple Push Notifications 功能。

採用元件

本檔案所述內容不限於特定硬體和軟體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

當集群啟用推送通知時，思科統一通訊管理器和IM and Presence服務使用Apple或Google雲的推送通知服務將推送通知傳送到在iOS或Android裝置上運行的相容Cisco Jabber或Webex客戶端。「推送通知」讓您的系統與使用者端通訊，即使已進入背景模式（也稱為暫停模式）也是如此。如果沒有推送通知，系統可能無法向進入後台模式的客戶端傳送呼叫或消息。

要使用Cisco Cloud進行身份驗證，您的Cisco Communications Manager伺服器會在自行啟用過程中生成令牌。如果您收到「400錯誤請求」消息，則推送通知服務的電腦訪問令牌已過期，您需要根據文檔手動更新訪問令牌：

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 IM and Presence：

Cisco 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 

您會在進行呼叫時在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 

這是已知的思科漏洞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:

使用實驗室刷新令牌更新電腦帳戶詳細資訊之後， 請重新啟動這些服務：

思科整合通訊管理員 ：：

• 思科管理代理服務(CMAS)
• 思科植入通知服務(CCMPNS)
• Tomcat

Cisco Unified Communications Manager IM and Presence：

• XCP組態管理器 
• XCP路由器
• Tomcat

這些服務必須在數小時後重新啟動，以避免任何服務影響。

驗證

現在，在包括IMP在內的所有節點上再次運行「運行sql select * from machineaccountdetails」，並立即驗證您是否具有我的刷新令牌。