《 MooH through CUBE操作、配置和故障排除指南》

下載選項

  • PDF     (1.4 MB)
    在多種裝置上使用 Adobe Reader 檢視
  • ePub     (1.2 MB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
  • Mobi (Kindle)     (562.3 KB)
    在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視
已更新: 2013 年 9 月 12 日
文件 ID:116392

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

本檔案介紹透過思科整合邊界元件(CUBE)進行多點傳送保留音樂(MMoH)的運作、組態和疑難排解資訊。

雖然本文的重點是組播通話等待音樂(MoH)，但相當一部分內容專門用於描述MoH的一般工作方式。此附加資訊有助於為初學者構建基礎知識，以便更好地識別和理解MoH特有的問題。

附註：雖然原則相同，但思科統一邊界要素服務提供商版(CUBE-SP)不屬於本文檔的範圍，在不涉及Cisco Unified Communications Manager(CUCM)的環境中使用CUBE也不屬於本文檔的範圍。

必要條件

需求 

本文件沒有特定需求。

採用元件

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

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

背景

附註：除了針對H.323展示的幾個場景外，本文的大部分內容中都使用作業階段啟始通訊協定(SIP)訊號。

MoH概述

每當呼叫者處於保持狀態時都會播放MoH。呼叫保持由使用者或網路在實施附加服務過程（如來電轉駁或轉移）時發起。前者稱為使用者啟動的保持、使用者保持或使用者保持。後者被表示為network-initiated hold、network-hold或network hold。

以下是MoH如何與分時多工(TDM)網關配合使用的概述。此圖說明呼叫保持方案涉及的元件和連線：

 

要使呼叫處於保持狀態，需要執行兩步流程。此圖說明了涉及的兩個步驟：

 

提示：當您嘗試對MoH配置進行排序和排除問題時，請記住此兩步過程。

MoH源

將呼叫置於保持狀態的使用者稱為holder，處於保持狀態（並聽到MoH）的使用者稱為holdee。每一端決定播放音樂的某些方面。

 

音樂源由保持器確定。決定遵循以下層次結構：

  1. 在域名(DN)上配置的音樂源
  2. 裝置上配置的音樂源
  3. 裝置配置檔案上的音樂源（僅限使用者保留音樂源）
  4. 全域性級別的音樂源（服務引數或示例）

有兩組音樂源，稱為user-hold和network-hold。每當提到音樂來源時，它可能表示使用者保持或網路保持音樂來源。

MoH端點

對於MoH，CUCM端的終端為MoH伺服器。瞭解這一點很重要，因為編解碼器確定（基於區域間編解碼器配置）基於：

  • MoH伺服器區域
  • 中繼/網關區域

一般建議是為MoH伺服器分配一個專用區域，以便該區域與所有其他區域之間的區域間編解碼器為g.711（或您要流出MoH的其他編解碼器）。

從CUCM的角度來看，呼叫中涉及的終端不是兩部電話，而是：

  • 註冊到CUCM的IP電話
  • 網關/CUBE

因此，CUCM將指向相關網關/CUBE的中繼視為終端，並檢視與其關聯的資源，以確定如何呈現音樂流。

MoH VoIP協定

MoH的定義是單向音訊對話。其訊號方式取決於使用的VoIP協定。例如，在SIP上，這通過direction屬性進行傳送。在H.323上，CUCM在H.245 Open Logical Channel Ack(OLCAck)消息中指定0000000作為網路地址，指定0作為MoH伺服器的埠(tsapIdentifier)。

附註：對於MMoH，CUCM會將組播地址（例如239.1.1.1）作為網路地址傳送。

在涉及CUBE的呼叫流中，CUCM不瞭解CUBE和Internet電話服務提供商(ITSP)之間的呼叫段。 CUCM僅涉及IP電話和SIP中繼（通向CUBE）之間的呼叫段。

MoH的信令流程類似於新會話的信令，範圍縮小。例如，在SIP中，對話在已存在的對話方塊上下文中進行。[1]

禁用媒體流

上述兩步流程的第一步是禁用媒體流。

此圖說明在SIP中如何禁用媒體流：

 

SIP實施對於屬性之一或兩者都不同(?a=?和？C=IN ?)用於指示媒體流已禁用。

此圖說明H.323中媒體流如何禁用：

  

連線到MoH

上述兩步過程的第二步是連線MoH。一旦音訊流被禁用，CUCM會發出單向MoH會話訊號，該會話會導致holdee收聽MoH源。

在此過程中，CUCM在確定流傳輸引數之前，會考慮持有者的媒體功能以及與中繼關聯的媒體資源組清單(MRGL)。因此，此的訊號總是延遲提供(DO)[2]（在SIP中）。

INVITE事務的實際數量有所不同。例如，CUCM僅通過一個DO INVITE事務將holdee連線到MoH。或者，DO INVITE用於收集保持者的媒體能力，並且隨後的EO INVITE用於實際將保持者連線到MoH。

此圖說明SIP的事務處理：

此圖說明H.323的事務處理：

此圖說明互通環境中的信令消息序列（例如，當CUBE的一端是SIP而另一端是H.323時）：

 

在呼叫中使用媒體資源時

媒體資源(MediaTermination Point(MTP)/轉碼器)在大多數情況下保護CUBE到IT服務提供商(ITSP)呼叫段。在通過CUBE的呼叫中使用媒體資源時，MoH的信令大多涉及CUCM和媒體資源之間的瘦客戶端控制協定(SCCP)消息。請注意，被置於保持狀態的媒體資源不是CUBE中繼。MTP/Transcoder收到偵聽MoH（假設SIP）的訊號後，CUCM會向CUBE傳送SIP UPDATE消息。這將更新branch引數，該引數標識新事務（MOH會話）。

繼續呼叫

恢復流程與暫掛流程相似，不同之處在於順序顛倒：

  1. 當前音訊流已禁用。
  2. 將傳送另一個DO re-INVITE，以便將holder重新連線到將呼叫置於保留狀態的電話。 

SDP屬性

作業階段說明通訊協定(SDP)中引入X-cisco-media:umoh屬性，以簡化跨叢集主幹(ICT)上的MoH訊號傳送[3]。通過使用不同協定的終端之間的互操作，CUCM通常執行不直觀的笨拙和中間信令。為了避免猜測，並使信令上下文顯性，使用名為X-cisco-media的專有SDP屬性。

在CUCM版本8.5及更高版本中，可以使用此屬性設定為Unicast Music on Hold(UMoH)或MMoH來向MoH發出信號，這樣可以消除對假埠值向被保留方指示MoH方案的依賴。

附註：這不會影響使用CUBE的MoH信令。

CUBE上的MoH

使用CUBE時，基本進程保持不變；但是，必須考慮[5] CUBE在Cisco IOS之前不轉碼MoH。版本15.3T。這意味著您必須小心影響CUCM到CUBE分支中的編解碼器選擇的因素，以便不需要轉碼器。

附註：此處引用的轉碼器是由CUBE（而不是CUCM）插入。 就CUCM而言，CUBE是目的地，並且在MOH伺服器到CUBE路徑中不涉及任何轉碼器。

編解碼器注意事項

一般情況下，有幾個因素會影響CUCM到CUBE分支中使用的編解碼器，但這些注意事項適用於MoH:

  • 無法轉碼MoH。[5]
  • MoH聽起來只適合G.711。

附註：本主題不在本文檔的討論範圍之內，因為許多好的文檔都有關編解碼器注意事項，此處介紹本主題是多餘的。

MoH

附註：到目前為止，本文檔中描述的大部分資訊都與MoH是採用單播還是多播IP資料包進行資料流相關。

MoH節省了系統資源和頻寬。組播允許多個使用者使用相同的音訊源流，以提供通話等待音樂。在任何需要頻寬節約很重要的企業網路中，都需要MoH。

以下是CUBE通過Internet將MMoH傳遞給ITSP時的一些關切和問題：

  • 組播流量的覆蓋範圍 — 思科將範圍239.0.0.0到239.255.255.255用於組播音樂。此範圍稱為管理範圍地址。此地址塊被視為專用地址塊，這意味著它被企業網路使用，永遠不應轉發到企業外部。邊界路由器通常相應地配置。
  • VPN組播 — 預設情況下，IP安全不支援MMoH。

這就是CUBE支援MMoH的方式：

  1. CUBE從MoH伺服器接收MoH資料包。
  2. 它將資料包轉換為單播IP資料包。
  3. CUBE將資料包轉發到ITSP。

SIP方向屬性操作

如RFC 3264中所述：

如果會話描述包含組播媒體流，該媒體流僅列為接收（傳送），則意味著參與者（包括發起者和傳送者）只能接收（傳送）該媒體流。這與單播檢視不同，單播檢視中的方向性是指提供商和應答者之間的媒體流。除此之外，提供的組播流的語義與RFC 2327 [1]中的描述完全相同」

因此，當CUCM傳送帶有組播IP地址的re-INVITE時，它將方向屬性設定為recvonly;但是，由於CUBE將組播資料包轉換為單播資料包，它必須將direction屬性設定為sendonly（僅對ITSP的支路執行）。

此圖說明了邏輯：

  

地址操作

在DO[6] re-INVITE傳送中，CUBE在SIP SDP C=IN欄位中傳送自己的IP地址。這是一個單播地址。

此映像提供端到端檢視：

 

附註：CUBE必須運行Cisco IOS版本15.2(2)T或更高版本，才能支援MMoH。 

來自快閃記憶體的流

藉助TDM網關，可通過直接從網關流式傳輸組播音樂實現額外的WAN頻寬節省。因此，如果MoH伺服器位於總部，而網關位於通過WAN連線的遠端分支機構，則傳送MoH的組播流量不必經過WAN（從總部到分支）並使用寶貴的WAN頻寬。

CUBE是中繼端裝置，不能流式傳輸來自本地快閃記憶體或通過任何模擬TDM介面的MMoH。仍然可以實現廣域網頻寬。通過使用遠端分支處的另一個支援語音的路由器作為MomH流的源來實現這一點。此路由器通過快閃記憶體傳輸MMoH。然後，可以向CUBE發出訊號以接收這些資料包、轉換這些資料包並作為單播資料包傳遞。

來自即時饋送的流

為了從即時饋送進行流式傳輸，必須配置另一台路由器，因為CUBE不是線路端裝置，如上一節所述。

配置MMoH

本節介紹如何在支援CUBE、CUCM和L3的交換機上配置MMoH。


在CUBE上配置MMoH

使用以下命令在CUBE上配置MMoH:

ccm-manager music-on-hold
ip multicast-routing

在CUCM上配置MMoH

按照以下步驟在CUCM上配置MMoH:

  1. 在MoH源、MoH伺服器和媒體資源組(MRG)上啟用組播功能。
  2. 使用步驟1中配置的MRG將MRGL分配給中繼。
  3. 在IP語音流應用服務引數中配置編解碼器。

附註：有關詳細的配置步驟，請參閱思科統一通訊系統9.0 SRND — 媒體資源文章的通話等待音樂部分。

在支援L3的交換機上配置MoH

使用以下命令在支援L3的交換器上設定MMoH:

ip routing
ip multicast-routing

在呼叫中使用MTP時

MTP不支援組播音樂。holdee只能收到空洞消息。[7]

附註：轉碼器也是MTP。

效能注意事項

在Cisco IOS中，所有MMOH資料包均進行進程交換。這對小型部署來說沒問題，但是對於大型安裝而言，這會對CUBE的效能產生重大影響。

限制

以下是使用MoH的限制清單：

  • CUBE必須位於Cisco IOS版本15.2(2)T或更高版本。
  • AS54xx不支援MoH。
  • ISR-G1（28xx、38xx系列）不支援MMoH
  • 請注意支援的編解碼器。

疑難排解

使用本節內容，對MoH進行疑難排解。 

Show和Debug命令

以下是show和debug命令及其含義的清單：

  • Show ccm-manager music - 幫助確認CUBE知道從何處偵聽多播音樂資料包，以及它是否收到這些資料包。.
    R1#show ccm-manager music
    Current active multicast sessions : 1

     Multicast       RTP port   Packets       Call   Codec    Incoming

     Address         number     in/out        id              Interface

    ===================================================================

    239.176.201.1     16384   956/956          237  g711ulaw  Se0/1/0 
  • Show ip igmp members — 用於檢查CUBE在接到偵聽組播音樂的通知時是否已成功加入組播組。

  • 以下三個命令用於檢查終端的協商編解碼器、IP地址和埠號:
    Show call active voice compact
    Show voip rtp conn
    Show sip calls
    以下是第一個命令的示例輸出：
    R1#show call active voice compact

     <callID>  A/O FAX T<sec> Codec       type        Peer Address       IP R<ip>:<udp>

    Total call-legs: 2

           236 ANS     T53    g711ulaw    VOIP        P1003    239.176.201.1:16384

           237 ORG     T53    g711ulaw    VOIP        P919789362814    200.200.200.2:17808
  • Show call active voice brief — 當呼叫處於保持狀態時發出此命令，以檢查rx/tx計數是否增加。
    0    : 236 29262010ms.1 (*22:34:23.659 UTC Fri May 10 2013)
     +4190 pid:1000 Answer 1003 connected
     dur 00:01:38 tx:919/147040 rx:918/146880 dscp:0 media:0 audio tos:0xB8 video tos:0x0
     IP 239.176.201.1:16384 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
     g711ulaw TextRelay: off Transcoded: No
     media inactive detected:n media contrl rcvd:n/a timestamp:n/a
     long duration call detected:n long duration call duration:n/a timestamp:n/a

    0    : 237 29262010ms.2 (*22:34:23.659 UTC Fri May 10 2013)
     +4190 pid:2000 Originate 919789362814 connected
     dur 00:01:38 tx:8910/1425600 rx:919/147040 dscp:0 media:0 audio tos:0xB8 video tos:0x0
     IP 200.200.200.2:17808 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
     g711ulaw TextRelay: off Transcoded: No
     media inactive detected:n media contrl rcvd:n/a timestamp:n/a
     long duration call detected:n long duration call duration:n/a timestamp:n/a
  • Show perf query class "Cisco MOH Device" — 此CUCM CLI命令用於快速檢查是否分配了MoH資源，以及分配了何種資源（單播或組播）。 當您有多個呼叫處於無保留狀態時，此命令並不是很有用，因為當呼叫處於保留狀態並恢復時，計數會動態變化。
    admin:show perf query class "Cisco MOH Device"

    ==>query class :

     - Perf class (Cisco MOH Device) has instances and values:

        MOH_2           -> MOHHighestActiveResources      = 0

        MOH_2           -> MOHMulticastResourceActive     = 0

        MOH_2           -> MOHMulticastResourceAvailable  = 250000

        MOH_2           -> MOHOutOfResources              = 1

        MOH_2           -> MOHTotalMulticastResources     = 250000

        MOH_2           -> MOHTotalUnicastResources       = 250

        MOH_2           -> MOHUnicastResourceActive       = 0

        MOH_2           -> MOHUnicastResourceAvailable    = 250
  • Debug ccm-manager music-on-hold — 此命令用於跟蹤呼叫段如何更改（例如，禁用當前音訊並連線MoH時），以及驗證CUBE是否按照CUCM的指示加入網際網路組管理協定(IGMP)組。
  • Debug ip packet - 此命令可替代Wireshark進行檢查。但是，此命令可能會迅速壓垮CPU。僅在絕對必要時使用；關閉控制檯日誌記錄，並且不要運行超過一秒。

案例 1

症狀 — 來自公共交換電話網路(PSTN)的呼叫與雙向音訊建立良好關係。但是，當IP電話將PSTN呼叫者置於保持狀態然後繼續呼叫時，單向音訊結果為：ip電話從PSTN聽到音訊，但PSTN使用者無法聽到IP電話。

首先，確保在有關的SIP中繼上未禁用Require SDP Inactive Exchange for Mid-Call Media Change[5]。這使CUCM能夠在SDP中傳送帶有a=inactive的re-INVITE，以便中斷存在的媒體路徑。

當呼叫處於保持狀態時，如果為SIP中繼[8]啟用了Send-receive SDP in mid-call INVITE複選框，則CUCM不會使用非活動SDP傳送重新INVITE以中斷媒體路徑。僅當介質模式設定為非活動狀態後無法提供完整(send-recv)服務的裝置才會檢查該配置。

以下是說明可用覈取方塊的影象：

附註：如需其他資訊，請參閱Cisco錯誤ID CSCtx84013。

案例 2

症狀 — 當呼叫者處於保持狀態而不是MoH時，只有提示音。

一般來說，這表明CUCM沒有分配MMoH。

  • 使用show perf query class?Cisco MOH Device?CUCM CLI命令，以驗證MOHOutOfResources計數是否增加。
  • 確保在MMoH源、伺服器和組上啟用組播。

案例 3

症狀 — 當呼叫者處於保持狀態時，僅會聽到死氣沈沈的聲音。

確保：  

  • CUBE和音訊路徑中的其他路由器上啟用了組播路由。
  • 在音訊路徑的第3層交換機上啟用了IP路由和組播路由。
  • ttl（跳數）配置在CUCM上的MoH伺服器上，並且足夠大以覆蓋跳。
  • 如果需要轉碼器，則成功分配它。
  • IP語音流應用上配置的編解碼器清單支援用於MoH的編解碼器。

案例 4

症狀 — 呼叫保持和恢復的循環模式中呼叫失敗。

為支援繞流，您必須從IPIPGW傳送重新邀請或更新；但是目前不支援這種設定。因此，不支援DO-EO呼叫的繞流。如果行銷部門有此類呼叫流程要求，將考慮提供支援。思科漏洞SIP SIP SS DO-EO:呼叫保持和恢復的呼叫在繞流模式中失敗，標籤為增強功能以供將來考慮。

相關資訊


[1]這可能令人困惑 — 您如何才能在對話中進行不同的對話？在SIP中，對話方塊指的是3個組<To tag， From tag， and Call-ID>。在保持階段，此3簇保持相同。

[2]執行 — 延遲提供。

[3] 集群間中繼

[4]從CUCM 8.5開始。

[5]轉碼在Cisco IOS版本15.3T及更高版本中適用於MMoH。 

[6]執行 — 延遲提供

[7] 思科統一通訊管理器功能和服務指南8.6(1)版

[8] 以下是用於配置SIP中繼的SIP配置檔案上的設定。

TAC Authored

由思科工程師貢獻

  • Bakthavatsal Muralidharan
    Cisco TAC Engineer.

這份文件是否有所幫助？

Feedback意見

讓思科協助您

本文件適用於這些產品