對註冊到Cisco CallManager的TC端點進行呼叫故障排除

簡介

本檔案將說明註冊到Cisco CallManager的Tandberg編解碼器(TC)終端所面臨的一些常見呼叫故障問題和建議的解決方案。

必要條件

需求

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

如何捕獲H.323調試日誌

附註：確保捕獲了安全套接字主機(SSH)會話輸出。

1. 通過SSH連線到編解碼器CLI並輸入以下命令：
   • log ctx H.323資料包調試9
   • log output on（這會將所有日誌輸出到SSH會話終端會話螢幕。）
2. 開始呼叫並重新建立問題。
3. 輸入log output off和log ctx H.323Packet debug off命令。

如何擷取作業階段啟始通訊協定(SIP)偵錯日誌

附註：確保捕獲SSH會話輸出。

1. 通過SSH連線到編解碼器CLI並輸入以下命令：
   • log ctx SIP資料包調試9
   • log output on（這會將所有日誌輸出到SSH會話終端會話螢幕。）
2. 開始呼叫並重新建立問題。
3. 輸入log output off 和log ctx SIPacket debug off 命令。

如何從TC終端收集資料包捕獲/終端日誌

1. 在Web GUI中選擇Diagnostics > Log files，並啟用帶有完整資料包捕獲的擴展日誌記錄。
2. 開始呼叫並重新建立問題。請注意，資料包捕獲只能啟用3分鐘。
3. 在Web GUI中選擇Diagnostics > Log files，然後下載完整的日誌歸檔檔案和資料包捕獲。

需要的其他資訊

• 在所有涉及的裝置上完成呼叫流程
• 被叫和主叫號碼
• 發生問題的日期和時間

採用元件

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

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

問題：由於CallManager上的呼叫搜尋空間(CSS)/分割槽問題導致的呼叫失敗

由於CUCM上的CSS/分割槽問題，註冊到Cisco Unified Communications Manager(CUCM)的兩個終端之間的呼叫可能會失敗。

捕獲呼叫端點SIP日誌。此「404 Not Found」消息出現在來自CUCM的終端SIP日誌中：

 |SIP/2.0 404 Not Found
 Via: SIP/2.0/TCP 172.16.2.55:5060;branch=z9hG4bK26e12a6fbed832;received=172.16.2.55
 Call-ID: 77fec00-564180a1-1eec8b-370210ac@172.16.2.55
 CSeq: 101 INVITE
 From: <sip:1502@172.16.2.55>;tag=158127671
 To: <sip:4659@172.16.2.53>;tag=654ba920aeef9e74
 User-Agent: Cisco-CUCM10.5
 Content-Length: 0

解決方案

完成以下步驟以檢查呼叫端點的CSS和被叫端點的分割槽。確保呼叫終結點的CSS具有被呼叫終結點的分割槽。

您可以在終端的Device和Line級別分配CSS:

1. 選擇Device > Phone，選擇終端並按一下線路，然後線上路級別檢查呼叫搜尋空間(CSS)。在本示例中，未線上級配置任何CSS。但是，如果目錄號碼級別有CSS，則其中一個CSS必須包含被調號碼的部分：

   

2. 檢查在電話級別分配的CSS。選擇Device > Phone，然後選擇相關呼叫端點：

   

3. 檢查被叫號碼的分割槽。選擇Device > Phone，選擇被叫裝置，按一下線路，然後選中Route Partion:

   

4. 在兩個端點上驗證分割槽和CSS後，檢查呼叫裝置的CSS是否具有被呼叫裝置的分割槽：

   

   如果找不到，則可能是「404 Not Found」錯誤的原因。

問題：15分鐘後（或任何特定時間後）的SIP呼叫丟棄

通常，在特定時間間隔內，呼叫丟棄是由防火牆、路由器等上配置的SIP計時器或TCP超時引起的。

解決方案

當呼叫在15分鐘準確斷開時，常見的常見問題是網路（防火牆、路由器）上配置的TCP超時小於SIP會話到期計時器。在CallManager上，SIP會話過期計時器預設設定為1800秒。

若要驗證這一點，請選擇Cisco Unified CM Administration > System > Service Parameters > Cisco Call Manager Service > Look for - SIP Session Expires Timer。

註冊到CUCM的所有終端都使用此計時器。當終端與其他遠端終端通話時，一方必須刷新會話並傳送重新邀請或更新。此刷新必須在會話過期計時器的一半之前傳送（1800/2 = 900秒= 15分鐘）。 如果沒有收到刷新消息，則呼叫將斷開。

在初始INVITE中檢查會話計時器。應在此時間到期之前收到刷新（邀請/更新）：

|INVITE sip:+1234@10.108.64.22:5060;transport=tcp SIP/2.0
 Via: SIP/2.0/TCP 10.110.68.38:5060;branch=z9hG4bK00eed555
 Call-ID: dbfe0000-4491f669-9fd00-16406c0a@10.108.64.22
 CSeq: 1 INVITE
 Contact: <sip:30048@example.com;gr=urn:uuid:f7a3a098-ead8-5512-85ef-26ae544d6547
   >;isfocus;x-cisco-tip
 From: "TP Conference 30048 - Test" <sip:30048@10.110.68.6>;tag=86251172C3B60000
 To: <sip:1234@10.108.64.22>;tag=25983910~226bf657-9d6c-4ad9-98a2-cf842fe1d733-52629917
 Max-Forwards: 70
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Allow: INVITE,ACK,CANCEL,OPTIONS,UPDATE,INFO,SUBSCRIBE,NOTIFY,BYE
 User-Agent: TANDBERG/518 (TC6.2.0.20b1616)
 Supported: timer,outbound,record-aware,X-cisco-callinfo
 Session-Expires: 1800;refresher=uac

根據初始使用者代理客戶端/使用者代理伺服器(UAC/UAS)協商，其中一個終端在傳送重新邀請時刷新會話。如果刷新程式是UAC，則呼叫的發起方有責任刷新會話。如果刷新程式是UAS，則伺服器必須刷新會話。從兩個終端收集SIP調試日誌並檢查以下專案：

範例：從A方到CUCM方到B方的呼叫。如果刷新程式是A方的UAC和B方的UAS:

1. 參與方A必須將重新邀請/更新傳送到CUCM。
2. CUCM必須向B方傳送重新邀請/更新。
3. 第B方收到re-INVITE並以200 OK響應該消息。
4. CUCM必須將200 OK傳送到參與方A。

如果一個終端向CUCM傳送re-INVITE消息，則CUCM向另一個終端傳送re-INVITE。但是，如果遠端端未收到此消息，則可能是由於中間存在一些網路裝置。由於SIP檢查或網路設定，重新INVITE/響應很可能無法到達其中一個端。

如果端點不啟動重新邀請，則可能是端點有問題。請與Cisco技術援助中心(TAC)聯絡，以便進一步調查。

問題：任何特定時間之後的H.323呼叫丟棄

與SIP一樣，在H.323中，通常由於網路或防火牆超時配置，會以特定時間間隔發生呼叫丟棄。

解決方案

在H.323呼叫中，每隔30秒在端點之間傳送一次往返延遲請求(RTDR)消息以及序列號。每個請求都應得到響應。

思科終端使用RTDR/往返延遲響應消息，該消息是H.245多媒體系統控制消息的一部分。這樣可在用於主動呼叫管理的呼叫期間保持H.245 TCP會話處於活動狀態。如果端點最初收到RTDR的響應，並且在呼叫期間沒有收到響應，則端點終止呼叫。

在此案例中，收集H.323調試日誌和終端日誌以隔離問題。從H.323調試日誌中檢查RTDR請求和響應消息，並檢視它是否丟棄。

在此示例輸出中，終端向遠端終端傳送RTDR請求，但不會從遠端終端接收響應。因此會斷開呼叫：

 014-09-23T21:37:01+10:00 corevcs1 tvcs: UTCTime="2014-09-23 11:37:01,
 711"Module="network.H.323" Level="DEBUG":  Dst-ip="10.0.20.11"  
 Dst-port="11012" Sending H.245 PDU: value MultimediaSystemControlMessage
 ::= request : roundTripDelayRequest : {   sequenceNumber 120

可使用序列號跟蹤請求和響應。

終端日誌中的以下示例顯示了斷開的原因：

2977610.83 H.323Call I: H.323_call_handler::handleDiscInd(p=349, s=1) 
Received disconnectindication (Cause: 12:18, H.323 cause: 3:18)- 
NetworkRejected Q85012977610.84 MC I: RemoteParticipant::
reevalRefMode(p=349,ch=2) set ref [Video (2): vid-off0x0@0.0  0k ] 
q= auto, t60=600012977610.84 ModesController I: ModesController::
resetRateLimit(ch=2)12977610.84 MC I: RemoteParticipant::modeChanged
(p=349, ch=2): ModesController wants torun mode: Video (2): vid-off 0x0@0.0  0k

問題：由於媒體資源分配失敗導致的呼叫失敗

在影片呼叫的情況下，會看到由於媒體資源分配失敗而失敗的呼叫。例如，如果呼叫方和被叫方終端不支援公共編解碼器，則需要使用轉碼器，對於雙音多頻(DTMF)不匹配，則需要在呼叫管理器上使用媒體終端點(MTP)。

解決方案

對於影片轉碼，需要資料包語音數字模組(PVDM3)數位訊號處理器(DSP)轉碼器，因為PVDM2上的轉碼器不支援影片。如果轉碼器/MTP不可用，則會向終端傳送503服務不可用消息：

SIP/2.0 503 Service UnavailableVia: SIP/2.0/TCP 10.101.15.13:
5060;branch=z9hG4bK954956da2012413dfb6ef80d6bc9e373.1;rportFrom:
 <sip:3550@10.102.254.4>;tag=47c4717d0db85e1aTo:
 <sip:1281@10.102.254.4>;tag=176803~66dd1c7a-eac9-42af-a69b-
18da1695a800-31478649Date: 
Wed, 19 Feb 2014 16:10:05 GMTCall-ID: 
c05df2acedcafd063eb5cf947ebc1efcCSeq: 100 INVITEAllow-Events: 
presenceReason: Q.850;cause=47Content-Length: 0 

為了解決此問題，請檢查媒體資源組/媒體資源組清單(MRG/MRGL)配置並確保影片編碼器/MTP可用。MRGL可以分配給電話級別或裝置池級別的裝置：

1. 在CallManger上，選擇Device > Phone，然後選擇出現問題的裝置，並檢查裝置池和MRGL設定：

   

2. 如果電話上的MRGL設定為None，則必須檢查裝置池設定以確儲存在代碼轉換器。
3. 選擇System > Device Pool，然後選擇分配給裝置的裝置池：

   

4. 選擇Media Resources > Media Resource Group List，然後選擇在電話級別/裝置池級別分配的MRGL，並檢查MRG:

   

5. 注意MRG，選擇Media Resources > Media Resource Group，然後選擇指定的MRG。確保已新增PVDM3硬體轉碼器/MTP。

   

問題：由於頻寬不足導致呼叫失敗

通常，由於CUCM中裝置上的區域/位置中的頻寬配置不足，呼叫會斷開連線。當區域設定為終端無法支援的低頻寬時，CallManager會傳送一個「488 Not Acceptable Media」，原因為125，這意味著SIP媒體協商發生後「Out of Bandwidth」或「Infficient Bandwidth」。

您需要按所述捕獲終端上的SIP日誌並查詢以下消息：

1459.81 SipPacket I: PacketDump: Proto: SIP, Direction: Incoming, Name: 488 
Not Acceptable Media, CSeq: 100 INVITE, RemoteAddress: 10.106.85.219:5060, 
CallId: 207b6ddb148ddf900ae2e2f844115837, Time: 1459811
	1459.81 SipPacket   SIP/2.0 488 Not Acceptable Media
	1459.81 SipPacket   Via: SIP/2.0/TCP 10.106.85.231:56280;
branch=z9hG4bK64e2eb4a1a3afd5f956a1547eb1c05ad.1;rport
	1459.82 SipPacket   Call-ID: 207b6ddb148ddf900ae2e2f844115837
	1459.82 SipPacket   CSeq: 100 INVITE
	1459.82 SipPacket   From: <sip:4657@example.com>;tag=2d98ee2065ba492d
	1459.82 SipPacket   To: <sip:1112@10.106.85.219>;
tag=10543~8c84fc84-78bb-de4d-3ac7-da2a9cab63d5-19683975
	1459.83 SipPacket   Server: Cisco-CUCM10.5
	1459.83 SipPacket   Date: Sun, 07 May 2015 14:36:41 GMT
	1459.83 SipPacket   Allow-Events: presence
	1459.83 SipPacket   Warning: 370 10.106.85.219 "Insufficient Bandwidth"
	1459.83 SipPacket   Reason: Q.850 ;cause=125
	1459.83 SipPacket   Content-Length: 0
	1459.83 SipPacket   
	1459.83 SipStack I: SipDialog(ui=3,s=9) sendInviteRejToStack (488:Not Acceptable Media)
	1459.84 SipCall I: sip_call_handler::handleSIPMCallRej(3/9/-1): Call rejected
 (cause: Not Acceptable Media)
	1459.84 MainEvents I: CallDisconnectRequested(p=3) remoteURI='sip:1112@10.106.85.219'
 cause=[normal('') 'LocalDisconnect']
	1459.84 MainEvents I: ParticipantLeftConference(c=2,p=3)
	1459.85 APPL_Media ERROR: AudioCtrlImpl::execute_disconnectInputOutput 
No mixer for (p=1,ch=61)
	1459.85 MainEvents I: CallDisconnected(p=3) remoteURI='sip:1112@10.106.85.219' 
causeToLocal=[disconnected('Not Acceptable Media') 'RemoteDisconnect'] 
causeToRemote=[normal('') 'LocalDisconnect']

解決方案

如果發生此問題，請檢查兩個端點上配置的Region並檢查它們之間的Region關係：

1. 選擇Device > Phone，然後選擇兩台裝置。檢查分配給裝置的裝置池：

   

2. 檢查裝置池後，在CUCM上選擇System > Device Pool，並檢查兩個裝置池上配置的區域：

   

3. 選擇System > Region Information > Regions，然後選中Region Relationship。檢查區域內的音訊影片頻寬，並確保終端可以在選定的音訊/影片頻寬下運行：

   

在上述螢幕截圖中，假設一個端點位於區域「Trunk Region」中，而另一個位於「Local Endpoints Region」中。

另一種解決方法是如果影片呼叫頻寬不足，則將影片呼叫嘗試為音訊呼叫。使用以下步驟進行檢查和設定：

1. 選擇Device > Phone，然後選擇出現問題的呼叫裝置。檢查此螢幕快照中的引數是否已選中。如果未選中此覈取方塊，請檢查該覈取方塊，以便在出現頻寬問題時影片呼叫回退到音訊：

   

   由於CallManager上的位置設定，可能發生此問題。

   位置可以在電話級別或裝置池級別分配（電話級別優先順序別較高）。

2. 若要檢查電話級別位置設定，請選擇Devices > Phones，然後檢查呼叫和被叫終端上的位置：

   

   該位置還可以應用於裝置池級別。因此，首先檢查兩個端點的裝置池：

   

3. 選擇System > Device Pool。在裝置池中，檢查在呼叫和被叫端點上分配的位置。在此示例中，未在裝置池級別分配位置。使用電話位置配置：

   

4. 檢查在呼叫和被叫端點位置之間是否配置了足夠的頻寬。在此示例中，假設一個端點位於本地端點位置，而另一個端點位於Hub_None位置，並且音訊/影片和沈浸式呼叫的頻寬均配置為「無限制」：

   

可能還有其它原因導致斷線。有關斷開原因代碼，請參閱Cisco Unified Communications Manager Call Detail Records Administration Guide， Release 10.0(1)的第178頁。