排解單向語音問題

簡介

本文檔介紹在涉及Cisco網關的IP電話單向音訊對話中可能出現的常見問題。 

必要條件

需求

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

• IP電話網路並具備語音網路的基本知識
• Cisco IOS^®閘道與路由器、Catalyst交換器和DT-24+閘道

採用元件

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

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

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

問題

本文提供解決以下問題的方案和解決方案：

• 通過Cisco IOS語音網關或路由器從IP站建立電話呼叫時，只有一方收到音訊（單向通訊）。

• 當兩個思科網關之間建立收費旁路呼叫時，只有一方接收音訊（單向通訊）。

• 從VPN 3002硬體客戶端之後的IP站建立電話呼叫時，只有一方收到音訊（單向通訊）。

解決方案

IP電話中單向音訊的原因可能多種多樣，但問題的根源通常涉及IP路由問題。本節介紹在現場發現的一些場景和解決方案。

確保Cisco IOS網關和路由器上啟用了IP路由

某些Cisco IOS網關（例如VG200）預設禁用IP路由。此預設設定會導致單向語音問題。

若要啟用IP路由，請在Cisco IOS閘道上發出以下全域組態命令：

voice-ios-gwy(config)#ip routing

檢查基本IP連線能力

請始終首先檢查基本IP可達性。由於即時傳輸協定(RTP)流是無連線（通過UDP傳輸），因此流量可以在一個方向成功傳輸，但在相反方向上會丟失。此圖顯示可能發生以下情況的情境：

子網A和B都可以到達子網X。子網X可以到達子網A和B。這允許在終端站（A和B）和Cisco CallManager之間建立TCP連線。因此，信令可以毫無問題地到達兩個終端站，這允許在A和B之間建立呼叫。

一旦呼叫建立，傳送音訊的RTP流必須在終端站之間雙向流動。在某些情況下，子網B可以到達子網A，但子網A不能到達子網B。因此，從A到B的音訊流總是丟失。

這是一個基本的路由問題。使用IP路由疑難排解方法，進入可以從閘道B成功ping通電話A的階段。請記住，ping是雙向驗證。

本文檔不涉及IP路由故障排除。但是，請確保這些是後續步驟：

• 預設網關在終端站配置。

• 這些預設網關上的IP路由通向目的網路。

以下清單說明如何驗證各種Cisco IP電話上的預設路由器或閘道組態：

• Cisco IP電話7910 — 按Settings，選擇選項6，然後按向下音量，直到顯示Default Router欄位。

• Cisco IP電話7960/40 — 按Settings，選擇選項3，然後向下滾動直到顯示Default Router欄位。

• Cisco IP電話2sp+/30vip — 按**#，然後按#，直到gtwy=出現。

驗證媒體終端點配置是否正確

如果為集群間中繼(ICT)配置了轉碼，請確保在與中繼關聯的媒體資源組和媒體資源組清單中配置了媒體終端點(MTP)。如果您在不需要時指定MTP，或在需要時未能配置MTP，則已知這會導致ICT配置的單向語音問題。

將H.323信令繫結到Cisco IOS網關和路由器上的特定IP地址

當Cisco IOS網關有多個活動IP介面時，某些H.323信令可以源自一個IP地址，而其它部分可以引用不同的源地址。這會產生各種各樣的問題。其中一個問題是單向音訊。

為了解決此問題，可以將H.323信令繫結到特定源地址。來源位址可屬於實體或虛擬介面（回送）。在介面配置模式下使用h323-gateway voip bind srcaddr ip-address 命令。使用Cisco CallManager指向的IP地址在介面下配置此命令。

此命令是在Cisco IOS軟體版本12.1(2)T中匯入。請參閱適用於虛擬介面的H.323支援。

將MGCP信令繫結到Cisco IOS網關上的MGCP媒體資料包源介面

如果未指定信令和媒體資料包的源介面，則單向語音可能會出現在媒體網關控制協定(MGCP)網關中。如果您發出mgcp bind media source-interface interface-id，可以將MGCP媒體繫結到源介面 命令，然後mgcp bind control source-interface interface-id 指令。發出命令後，在Cisco CallManager中重置MGCP網關。

如果未啟用mgcp bind命令，則IP層仍會提供最佳本地地址。

mgcp bind命令的指導如下：

• 當網關上有活動的MGCP呼叫時，會拒絕控制和介質的mgcp bind命令。

• 如果繫結介面未啟動，則接受該命令，但直到介面啟動時才生效。

• 如果未在繫結介面上分配IP地址，則接受mgcp bind命令，但僅在分配有效的IP地址後生效。在此期間，如果MGCP呼叫已啟動，mgcp bind命令將被拒絕。

• 當繫結介面由於介面上的手動關閉或操作故障而關閉時，該介面上的繫結活動將被禁用。

• 在媒體網關控制器(MGC)上未配置繫結時，用於源MGCP控制和媒體的IP地址是最佳可用IP地址。

檢查電話公司或交換機是否正確傳送和接收應答監督

如果您有連線到電信公司或交換機的Cisco IOS網關，請確認當電信公司或交換機後面的被叫裝置應答呼叫時，應答監督是否正確傳送。無法接收應答監控導致Cisco IOS網關無法沿轉發方向切斷（開啟）音訊路徑。此故障導致單向語音。因應措施是發出voice rtp send-recv on命令。

如需詳細資訊，請參閱使用Cisco IOS閘道和路由器上的voice rtp send-recv指令提前剪下雙向音訊。

在Cisco IOS網關和路由器上使用voice rtp send-recv命令提前切斷雙向音訊

在RTP流的開始處，在反向方向上建立語音路徑。在Cisco IOS網關收到來自遠端端的Connect消息之前，轉發音訊路徑不會通過。

在某些情況下，一旦開啟RTP通道，就需要建立雙向音訊路徑，即接收Connect消息之前。為此，請發出voice rtp send-recv 全域性配置命令。

在Cisco IOS網關和路由器上逐條鏈路檢查cRTP設定

此問題適用於通行費旁路等案例，其中語音路徑中涉及多個Cisco IOS路由器或閘道且使用壓縮RTP(cRTP)。cRTP或RTP標頭壓縮是使VoIP封包標頭變小以便重新獲得頻寬的一種方法。cRTP採用VoIP封包上的40位元組IP、使用者資料包通訊協定(UDP)或RTP標頭，並將其壓縮為每封包2至4位元組。對於使用cRTP的G.729編碼呼叫，此壓縮產生了大約12 kbps的頻寬。有關cRTP的詳細資訊，請參閱IP語音 — 每次呼叫的頻寬消耗。

cRTP是逐跳完成的，每個跳都經過解壓縮和再壓縮。必須檢查每個資料包報頭是否進行路由。因此，需要在IP鏈路的兩端啟用cRTP。

驗證鏈路兩端的cRTP是否按預期工作也很重要。Cisco IOS軟體版本層級在交換路徑和併發cRTP支援方面有所不同。

總而言之，歷史如下：

• 在低於Cisco IOS軟體版本12.0(5)T的Cisco IOS軟體版本中，cRTP是程式交換型。

• 在Cisco IOS軟體版本12.0(7)T和Cisco IOS軟體版本12.1(1)T中，引入了對cRTP的快速和Cisco快速轉送(CEF)交換支援。

• 在Cisco IOS軟體版本12.1(2)T中，引入了演演算法效能提升。

如果您在Cisco IOS軟體平台（Cisco IOS軟體版本12.1）上執行cRTP，請確認Cisco錯誤ID CSCds08210不會影響您的Cisco IOS軟體版本。此錯誤的症狀是VoIP和透過IP傳輸的傳真無法使用RTP標頭壓縮。

只有註冊的思科使用者才能存取內部思科錯誤資訊和工具。

驗證Cisco IOS網關上的時鐘配置

如果您在show controller {e1的E1或T1介面上找到時鐘滑動 | t1}命令，語音網關上的時鐘配置可能存在一些不匹配。請參閱支援語音的Cisco IOS型平台上的計時設定，並確保語音閘道上的計時設定正確。

檢驗Cisco IOS網關和路由器上的NAT最低軟體級別

如果使用網路地址轉換(NAT)，則必須滿足最低軟體級別要求。早期版本的NAT不支援精簡協定轉換。這些早期版本會導致單向語音問題。

對於Cisco IOS網關，必須運行Cisco IOS軟體版本12.1(5)T或更高版本，才能同時支援精簡版和H.323版本2（帶NAT）。有關詳細資訊，請參閱對Cisco CallManager的IP電話的NAT支援。

在PIX防火牆上同時使用NAT和skinny所需的最低軟體級別為6.0。有關詳細資訊，請參閱Cisco PIX防火牆版本6.0。

在AS5350和AS5400上禁用語音快速路徑

Cisco IOS軟體命令voice-fastpath enable是AS5350和AS5400的隱藏全域性配置命令。該命令預設啟用。若要停用它，請發出no voice-fastpath enable全域組態指令。

啟用該命令後，它會快取為特定呼叫開啟的邏輯通道的IP地址和UDP埠號資訊。該命令可防止RTP流到達應用層。相反，資料包是在較低層轉發的。這有助於在高呼叫量情況下將CPU利用率降至最低。

使用保持或傳輸等輔助服務時，voice-fastpath命令會使路由器將音訊流到快取的IP地址和UDP埠。在保持的呼叫恢復之後或傳輸完成之後生成的新邏輯通道資訊被忽略。為了解決此問題，流量必須不斷地流向應用層，以便考慮邏輯通道的重新定義，並將音訊流傳輸到新的IP地址和UDP埠對。因此，請務必禁用voice-fastpath，以便支援附加服務。

使用軟體電話配置VPN IP地址

Cisco IP SoftPhone使PC可以像Cisco IP Phone 7900系列電話一樣工作。通過虛擬專用網路(VPN)連線到公司網路的遠端使用者必須配置一些其他設定以避免單向語音問題。這是因為媒體流需要知道連線的端點。

解決方案是在Network Audio Settings下配置VPN IP地址，而不是網路介面卡的IP地址。有關詳細資訊，請參閱如何使用Cisco IP SoftPhone over VPN。

配置VPN 3002在網路擴展模式下工作

Cisco VPN 3002硬體客戶端可以在兩種模式下運行：客戶端模式和網路擴展模式(NEM)。在客戶端模式中，Cisco VPN 3002客戶端後面的所有主機都是埠地址，已轉換為VPN 3002客戶端的外部IP地址。H.323不與埠地址轉換(PAT)一起使用，當IP電話放在VPN 3002客戶端後面時，會以單向音訊方式輸出。當VPN 3002在NEM中工作時，遠端網路可通過其真實IP地址相互檢視，而不是通過基於NAT或基於PAT的IP地址相互檢視。如果VPN 3002配置為在NEM中工作，則H.323可以工作。換句話說，VPN 3002客戶端之後的IP電話只能在VPN 3002在NEM中工作時使用。因此，為了避免與VPN 3002客戶端有關的單向語音問題，請將VPN 3002客戶端配置為使用NEM。

要將Cisco VPN 3002硬體客戶端配置為使用NEM，請選擇Configuration > Quick > PAT，然後在PAT視窗中按一下No， use Network Extension mode。

有關詳細資訊，請參閱在網路擴展模式下使用EzVPN配置Cisco VPN 3002硬體客戶端到Cisco IOS路由器

其他資訊：驗證單向音訊

用於驗證資料包流的兩個有用命令是debug cch323 rtp命令和debug voip rtp命令。debug cch323 rtp 命令顯示路由器傳輸(X)和接收(R)的資料包。大寫字元表示成功傳輸或接收。小寫字元表示丟棄的資料包。

voice-ios-gwy#debug cch323 rtp

RTP packet tracing is enabled
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#

!--- This is an unanswered outgoing call. !--- Notice that the voice path only cuts through in the forward direction and 
!--- that packets are dropped. Indeed, received packets are traffic from the !--- IP phone to the PSTN phone. These are dropped until the call is answered. 
Mar 3 23:46:23.690: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXXrrrrrrrrrrrrrrrr
voice-ios-gwy#
voice-ios-gwy#

!--- This is an example of an answered call:

voice-ios-gwy#
voice-ios-gwy#
*Mar 3 23:53:26.570: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXr
XrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

!--- At this point, the remote end picks up the phone.

*Mar 3 23:53:30.378: ****** cut through in BOTH direction *****
XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXR
XXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR

!--- This is the end of the conversation.

voice-ios-gwy#debug voip rtp

--------cut through in BOTH direction-------------------

*Mar 27 19:52:08.259: RTP(32886): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFBF0, ssrc=8E5FC294
*Mar 27 19:52:08.275: RTP(247): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00C8D9, ssrc=1F1E5093
*Mar 27 19:52:08.279: RTP(32887): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFC90, ssrc=8E5FC294
*Mar 27 19:52:08.295: RTP(248): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00C979, ssrc=1F1E5093
*Mar 27 19:52:08.299: RTP(32888): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFD30, ssrc=8E5FC294
*Mar 27 19:52:08.315: RTP(249): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CA19, ssrc=1F1E5093
*Mar 27 19:52:08.319: RTP(32889): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFDD0, ssrc=8E5FC294
*Mar 27 19:52:08.335: RTP(250): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CAB9, ssrc=1F1E5093
*Mar 27 19:52:08.339: RTP(32890): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFE70, ssrc=8E5FC294
*Mar 27 19:52:08.355: RTP(251): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CB59, ssrc=1F1E5093
*Mar 27 19:52:08.359: RTP(32891): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFF10, ssrc=8E5FC294
*Mar 27 19:52:08.375: RTP(252): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CBF9, ssrc=1F1E5093
*Mar 27 19:52:08.379: RTP(32892): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFFB0, ssrc=8E5FC294
*Mar 27 19:52:08.395: RTP(253): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CC99, ssrc=1F1E5093
*Mar 27 19:52:08.399: RTP(32893): fs rx d=10.48.79.181(20002),
pt=0, ts=500050, ssrc=8E5FC294
*Mar 27 19:52:08.976: RTP(282): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DEB9, ssrc=1F1E5093
*Mar 27 19:52:08.980: RTP(32922): fs rx d=10.48.79.181(20002),
pt=0, ts=501270, ssrc=8E5FC294
*Mar 27 19:52:08.996: RTP(283): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DF59, ssrc=1F1E5093
*Mar 27 19:52:09.000: RTP(32923): fs rx d=10.48.79.181(20002),
pt=0, ts=501310, ssrc=8E5FC294
*Mar 27 19:52:09.016: RTP(284): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DFF9, ssrc=1F1E5093

通過PIX防火牆收集呼叫通訊資訊

您可以通過收集通過PIX防火牆的呼叫通訊資訊來排除單向呼叫故障。PIX capture 命令可用於驗證埠是否開啟，並在發生呼叫時使用。有關通過PIX防火牆的VoIP流量的詳細資訊，請參閱使用PIX防火牆處理VoIP流量。

Cisco Unified Communications Manager單向音訊問題

只有在需要MTP的傳出初始SIP呼叫設定中才會出現此問題。在這種情況下，傳出SIP INVITE消息可以包含SDP提議。在下列情況下可能會出現問題：

• 在SIP中繼上選中了需要媒體終端點的傳出SIP中繼呼叫

• 僅IPv6終端和僅IPv4終端之間的呼叫

解決方案

MTP資源可能會間歇性洩漏，從而導致需要MTP資源的SIP呼叫失敗。在RTMT中，可用的MTP資源達到0，需要MTP的每個呼叫的MTP分配失敗計數增加。初始INVITE的SDP部分可能錯誤地包含a=inactive。

完成以下步驟即可解決問題：

1. 如果可能，取消選中SIP中繼配置上的Media Termination Point Required。

2. 如果需要提前提供，請配置「提前提供」，但保留未選中的「需要介質終止點」。

3. 對於IPv6部署，請使用雙協定棧，而不是僅使用IPv6的終端。

相關資訊

• CallManager H.323：轉接或保留後的單向語音問題
• NAT — 對Cisco CallManager的IP電話支援
• 適用於虛擬介面的H.323支援
• 在網路擴展模式下使用EzVPN配置Cisco VPN 3002硬體客戶端到Cisco IOS路由器
• 採用Cisco CallManager的Cisco Unity：單向音訊
• 為Cisco Unity配置雙NIC並排除故障
• 語音技術支援
• 語音和整合通訊產品支援
• Cisco IP電話故障排除
• 思科技術支援與下載