通過Expressway解決企業對企業呼叫最常見的問題
目錄
簡介
本文檔介紹企業到企業(B2B)部署中最常見的問題。如何通過Expressway排除B2B呼叫故障。
必要條件
需求
思科建議您瞭解以下主題：
- Expressway-C(Exp-C)
- Expressway-E
- Cisco Unified Call Manager(CUCM)
- Telepresence Video Communication Server-C(VCS-C)
採用元件
本文中的資訊係根據以下軟體和硬體版本：
- Expressway C和E X8.1.1或更高版本
- Unified Communications Manager(CUCM)10.0或更高版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
常見問題
1.錯誤「//SIP/SIPTcp/wait_SdlReadRsp:忽略大消息。最多允許5000位元組。正在重置連線。」
從註冊到VCS的網真終端的呼叫，從會話發起協定(SIP)中繼到CUCM的入站，失敗並顯示「//SIP/SIPTcp/wait_SdlReadRsp:忽略大消息。最多允許5000位元組。正在重置連線。」
Expressway-C/VCS-C中的呼叫路由配置正確，呼叫將傳送到CUCM。SIP邀請消息傳送到CUCM，但在SDL日誌中沒有SIP消息。在SDL日誌中可以看到以下錯誤：
「|應用資訊 |SIPTcp — 忽略來自xxx.xxx.xxx.xxx的大型消息：[27469]。最多允許5000位元組。正在重置連線。」
在CUCM 8.6中，在CUCM 9.X更改為11000之後，SIP最大傳入消息大小的預設值是5000。但是，從8或更低版本升級到版本9或10將保留以前版本的軟體(5000)中的預設值。
解決方案
此問題與錯誤CSCts00642相關
將CUCM高級服務引數SIP Max Incoming Message Size從預設值5000增加到足以滿足這些型別的呼叫的大小。11000多數預期客戶場景而言，這似乎是一個很好的價值。
在CUCM管理頁面中，導航到服務引數，然後選擇您的CUCM伺服器和CallManager服務:
選擇Advanced選項並搜尋SIP Max Incoming Message Size:
2.如果另一個呼叫伺服器轉移呼叫，則媒體流停止。
在移動和遠端訪問(MRA)以及B2B呼叫中可能會發生這種情況。
在轉接呼叫後，它可能會單向不發出聲音或產生嗡嗡聲（當您嘗試使用加密音訊播放捕獲時發出同樣的噪音）。發生這種情況是因為在呼叫設定中選擇了加密套件，而傳送該加密套件至的終端不支援該設定。
您可以比較來電轉駁之前和之後的SIP協商。在VCS或CUCM日誌中的第一次協商中，您可以看到來自VCS的200 OK消息中的加密行：
m=audio 54582 RTP/SAVP 9 96 97 0 8 18 101 a=rtpmap:9 G722/8000 a=rtpmap:96 G7221/16000 a=fmtp:96 bitrate=32000 a=rtpmap:97 G7221/16000 a=fmtp:97 bitrate=24000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ckXijkT3CcVY+xlOf3ozX/TjHPz05OzEdY49rAHA|2^48 a=sendrecv a=rtcp:54583 IN IP4 10.1.201.7 m=video 54658 RTP/SAVP 96 97 b=TIAS:4000000 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e01e;max-fs=1621;packetization-mode=1;max-rcmd-nalu-size=32000;level-asymmetry-allowed=1 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42e01e;max-fs=1621;packetization-mode=0;level-asymmetry-allowed=1 a=rtcp-fb:* nack pli a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:S8BJvGB/2l6F7XP8izXxId443Xd9f27oUI/4gxSt|2^48
第一次呼叫接受加密行，但在第二次呼叫中，您會看到ACK消息刪除了加密行：
m=audio 24826 RTP/AVP 0 c=IN IP4 10.1.231.30 a=ptime:20 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 126 c=IN IP4 10.1.98.80 b=TIAS:448000 a=label:11 a=rtpmap:126 H264/90000 a=fmtp:126 profile-level-id=42E01F;packetization-mode=1;max-fs=3601;max-rcmd-nalu-size=32000;level-asymmetry-allowed=1 a=content:main
VCS嘗試使用開始時協商的加密行，即使來電轉駁到的終端不支援加密。
解決方案
此問題與錯誤CSCuv11790相關
將VCS/Expressway升級到x8.6.1以解決此問題。
3. CUCM中未配置頂級域。
如果未設定頂級域企業引數，則會導致CUCM將入站呼叫路由到自己的域，並且使用SIP路由模式。這可能會導致環路，因為呼叫最有可能被傳送回Exp-C，或者呼叫失敗並出現「404 Not Found（404未找到錯誤）」。
解決方案
在「CUCM管理」頁面中，導航到系統>企業引數以更改此設定
4. CUCM證書必須應用客戶端身份驗證屬性。
當Exp-C與CUCM之間設定了安全連線（TLS驗證開啟）時，SSL握手由特定呼叫伺服器啟動，該伺服器取決於呼叫方向。這表示兩台伺服器的憑證中都必須有使用者端和伺服器驗證。如果屬性不存在，則在VCS/Expressway日誌中會出現此錯誤：
Line 190: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,060" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connecting" Line 239: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,071" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connection Established" Line 249: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,081" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connection Closed" Reason="no certificate returned"
解決方案
有關如何使用Web客戶端和伺服器屬性配置模板的詳細資訊，請參閱VCS證書指南
5.互通性問題。
VCS/Expressway版本X8.6.x的互通過程存在一些問題。
與問題相關的錯誤：
如果檢查來自VCS/Expressway的診斷日誌中是否存在被拒絕的影片m線，則檢測缺陷CSCuw85626:
當協商H323流的TCS部分中的媒體行時，會顯示此錯誤消息。
媒體索引：1
已拒絕：true， direction:SDP_MEDIA_DIR_SENDRECV
type:影片/SDP_MF_AU_VID
缺陷CSCuw85715類似，但在本例中，VCS/Expressway日誌將指定原因為dataTypeNotSupported:
2015-10-29T09:49:00+04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-10-29 05:49:00,197" Module="network.h323" Level="INFO": Action="Sent" Dst-ip="XXXXXXXXXXXXXXXX" Dst-port="49162"
Detail="Sending H.245 OpenLogicalChannelRejResponse "
2015-10-29T09:49:00+04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-10-29 05:49:00,197" Module="network.h323" Level="DEBUG": Dst-ip="XXXXXXXXXXXXXXXX" Dst-port="49162"
Sending H.245 PDU:
value MultimediaSystemControlMessage ::= response : openLogicalChannelReject :
{
forwardLogicalChannelNumber 3,
cause dataTypeNotSupported : NULL
}
解決方案
升級到X8.7或更高版本。
6.從CUCM收到的ACK消息不會傳送到VCS-E/Expressway-E。
當配置的遍歷區域未指向VCS Expressway/Expressway-E的正確IP地址時，通常會出現這種情況。
在單個NIC部署中（在Expressway/Edge上），控制/核心上的穿越客戶端區域需要指向穿越伺服器的公共IP地址。
在雙NIC部署中，穿越客戶端需要指向穿越伺服器的內部IP地址（內部NIC通常是LAN1，但可以是LAN2）。請記住，這是內部LAN的內部IP地址。
解決方案
請參閱Cisco VCS Expressway和VCS控制 — 基本配置的附錄4，瞭解更多資訊以及不同網路部署的圖表。
7. CUCM丟棄入站呼叫上的TCP會話
從VCS控制/Expressway核心轉送呼叫時，CUCM可能會通過丟棄TCP會話拒絕此請求。
當鄰居區域和sip中繼安全配置檔案之間的埠不匹配或配置為5060/5061時，可能會發生這種情況。
MRA使用線內通訊，而B2B呼叫使用中繼通訊，CUCM具有不允許線內通訊和中繼通訊通過同一埠的限制。由於MRA大多數情況下是自動配置的，因此B2B部署需要使用不同的埠。
解決方案
為此，在CUCM的鄰居區域上配置的目的地埠（在VCS-C/Expressway-C上）需要不同於5060/5061，通常使用5065，但可以使用其他埠，配置的埠需要與在CUCM上分配給此伺服器的SIP中繼的SIP中繼安全配置檔案中配置的埠匹配。
在CUCM Administration頁面中，導航到Device > Trunk。
埠5065的SIP中繼安全配置檔案。
SIP中繼目的地連線埠可以是5060/5061，如下圖所示。
VCS/Expressway鄰居區域中的SIP埠需要與SIP中繼安全配置檔案中配置的埠匹配，如圖所示。
在Expressway管理頁面，導航到Configuration > Protocols > SIP
VCS沒有此限制或不適用於此場景，這意味著SIP中繼本身可以配置為5060/5061。
8. VCS無法正確解析FQDN或無法查詢SRV記錄。
對於源自CUCM的B2B呼叫，由於CUCM處理和路由呼叫方式的性質，可能會引入問題。
當CUCM向VCS伺服器轉發呼叫時，CUCM傾向於在撥打URI的末尾新增：5060或：5061（取決於配置），即test@lab.local >> test@lab.local:5060，當它到達expressway並向DNS區域點選搜尋規則時，VCS不會查詢SRV記錄，而只是查詢A或AAA記錄。您可以在VCS/Expressway的診斷日誌中確認這一點。
解決方案
為了解決此問題，只需建立一個轉換，用於在埠到達DNS區域之前刪除其末端（在任一伺服器上，這其實並不重要）。
在「Expressway管理」頁中，導覽 到配置>撥號計畫>轉換y配置>撥號計畫>轉換
轉換示例：
如果由於某種原因不能建立轉換，也可以通過搜尋規則完成轉換，但建議通過轉換完成。
在Expressway管理頁面，導航到Configuration > Dial Plan > Transforms y Configuration > Dial Plan > Search Rules
意見