簡介
本文檔介紹在涉及Cisco網關的IP電話單向音訊通話中可能出現的常見問題。
必要條件
需求
思科建議您瞭解以下主題:
- IP電話網路並具備語音網路的基本知識
- Cisco IOS®網關和路由器、Catalyst交換機和DT-24+網關
採用元件
本檔案所述內容不限於特定軟體或硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
慣例
如需文件慣例的詳細資訊,請參閱思科技術提示慣例。
問題
本檔案提供下列問題的情境和解決方案:
-
透過Cisco IOS語音網關或路由器從IP站建立電話呼叫時,只有一方接收音訊(單向通訊)。
-
當兩個Cisco網關之間建立收費旁路呼叫時,只有一方接收音訊(單向通訊)。
-
從位於VPN 3002硬體客戶端後面的IP站建立電話呼叫時,只有一方接收音訊(單向通訊)。
解決方案
IP電話中單向音訊的原因多種多樣,但問題的根源通常涉及IP路由問題。本節將介紹一些在現場發現的場景和解決方案。
確保在Cisco IOS網關和路由器上啟用了IP路由
某些Cisco IOS網關(例如VG200)預設停用IP路由。此預設設定會導致單向語音問題。
注意:在繼續閱讀下面的內容之前,請確保您的路由器上已啟用IP路由。換句話說,請保證路由器沒有執行no ip routing全局配置命令。
要啟用IP路由,請在您的Cisco IOS網關上發出以下全局配置命令:
voice-ios-gwy(config)#ip routing
檢查基本IP可接通性
務必首先檢查基本IP可接通性。由於即時傳輸協定(RTP)流是無連線的(透過UDP傳輸),因此流量可能在一個方向成功傳輸,但在相反方向丟失。此圖表顯示可能發生此情況的案例:
![fix_1way_voice.gif](https://www.cisco.com/c/dam/en/us/support/docs/voice/voice-quality/5219-fix-1way-voice.gif)
子網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=出現。
注意:使用Cisco IP SoftPhone應用程式時,如果機箱中安裝了多個網路介面卡(NIC),請確保機箱提供正確的NIC。IP SoftPhone軟體版本1.1.x中通常存在此問題。1.2版必須解決此問題。
注意:使用Cisco DT-24+網關時,請檢查DHCP作用域,並確保作用域中存在Default Gateway (003路由器)選項。003路由器引數填充裝置和PC中的Default Gateway欄位。範圍選項3必須具有可為網關路由的路由器介面的IP地址。
驗證正確的媒體終端點配置
如果為集群間中繼(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支援。
注意:Cisco IOS軟體版本12.2(6)中存在Bug,在此版本中,此解決方案實際上可能會引起單向音訊問題。有關詳細資訊,請參閱Cisco Bug ID CSCdw69681。只有註冊思科使用者才能訪問內部思科工具和資訊。
將MGCP信令繫結到Cisco IOS網關上的MGCP媒體資料包源介面
如果未指定信令和媒體資料包的源介面,則單向語音可能會出現在媒體網關控制協定(MGCP)網關中。如果發出mgcp bind media source-interface interface-id命令,然後發出 mgcp bind control source-interface interface-id命令,則可以將MGCP媒體繫結到源介面。在您發出命令後,在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 bug ID CSCds08210是否不會影響您的Cisco IOS軟體版本。此Bug的症狀是VoIP和IP傳真無法與RTP報頭壓縮配合使用。
只有已註冊的思科使用者可以存取內部思科錯誤資訊和工具。
驗證Cisco IOS網關上的時鐘配置
如果您發現E1或T1介面上存在來自show controller {e1 | t1}命令發現在E1或T1介面上存在時鐘滑動,則在語音網關上可能存在一些時鐘配置不匹配。請參閱在有語音能力的基於Cisco IOS的平台上的時鐘配置,並確保語音網關上的時鐘配置正確。
在Cisco IOS網關和路由器上驗證NAT的最低軟體級別
如果使用網路地址轉換(NAT),則必須滿足最低軟體級別要求。早期版本的NAT不支援skinny協定轉換。這些早期版本導致單向語音問題。
您必須為Cisco IOS網關運行Cisco IOS軟體版本12.1(5)T或更高版本,才能同時支援skinny和H.323版本2(含NAT)。有關詳細資訊,請參閱對Cisco CallManager的IP電話NAT支援。
注意:如果您的Cisco CallManager使用與預設埠(2000)不同的TCP埠傳送skinny信令,則必須調整NAT路由器。發出ip nat service skinny tcp port number全局配置命令。
在PIX防火牆上同時使用NAT和skinny的最低軟體級別為6.0。有關詳細資訊,請參閱Cisco PIX防火牆版本6.0。
注意:這些級別的軟體未必支援獲得完全網守支援所需的所有「註冊」、「准入」和「狀態」(RAS)消息。網守支援不在本文檔的討論範圍之內。
停用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以支援附加服務。
使用SoftPhone配置VPN IP地址
Cisco IP SoftPhone允許PC像Cisco IP Phone 7900系列電話一樣工作。透過虛擬專用網路(VPN)連線到公司網路的遠端使用者必須配置一些其他設定,以避免單向語音問題。這是因為媒體流需要知道連線的端點。
解決方案是在「Network Audio Settings(網路音訊設定)」下配置VPN IP地址,而不是網路介面卡的IP地址。有關詳細資訊,請參閱如何在VPN上使用Cisco IP SoftPhone。
將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。
有關詳細資訊,請參閱將Cisco VPN 3002硬體客戶端配置為EzVPN為網路擴展模式的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.
注意:在Cisco IOS軟體版本12.2(11)T和更新版本中,debug cch323 rtp command-line interface (CLI)命令已由debug voip rtp命令取代。
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流量。
注意:在生成故障排除所需的捕獲檔案後,請確保停用capture命令。
Cisco Unified Communications Manager單向音訊問題
此問題僅發生在需要MTP的傳出初始SIP呼叫設定中。在這種情況下,傳出SIP INVITE消息可以包含SDP提議。在下列情況下可能會發生此問題:
解決方案
MTP資源可能會間歇性洩漏,從而導致需要MTP資源的SIP呼叫失敗。從RTMT,可用MTP資源達到0,對於需要MTP的每個呼叫,MTP分配失敗計數增加。初始INVITE的SDP部分可能錯誤地包含a=inactive。
請完成以下步驟以解決問題:
-
如果可能,取消選中SIP中繼配置上的Media Termination Point Required。
-
如果需要Early Offer,請配置Early Offer,但將Media Termination Point Required保留為未選中。
-
對於IPv6部署,請使用雙堆疊,而不是僅使用IPv6的終端。
注意:此錯誤消息已記錄在Cisco Bug ID CSCtk77040中。 只有已註冊的思科使用者才能訪問內部思科錯誤工具和資訊。
相關資訊