MMoH至CUBE操作、配置和故障排除指南

简介

本文档介绍通过思科统一边界元素(CUBE)的组播通话等待音乐(MMoH)的操作、配置和故障排除信息。

虽然本文档的重点是组播通话等待音乐(MoH)，但主要部分致力于描述MoH的一般工作方式。此附加信息有助于为初学者建立基础知识，以便更好地认识和理解特定于MoH的问题。

注意：虽然原则相同，但思科统一边界元素服务提供商版(CUBE-SP)不属于本文档的范围，在不涉及思科统一通信管理器(CUCM)的环境中，CUBE的使用也不属于本文档的范围。

先决条件

要求 

本文档没有任何特定的要求。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

背景

注意：除了为H.323说明的几个场景外，本文档的大部分内容都使用会话初始协议(SIP)信令。

MoH概述

每当呼叫者被置于保持状态时，都会播放MoH。呼叫保持由用户或网络在实施补充服务流程时发起，例如呼叫前转或转接。前者称为用户发起的暂候、用户暂候或用户。后者被改为网络发起的保持、网络保持或网络。

下面回顾了MoH如何与时分复用(TDM)网关配合工作。此图显示了呼叫保持方案涉及的组件和连接：

 

要保留呼叫，需要分两步进行。此图说明了涉及的两个步骤：

 

提示：在尝试对MoH配置进行排序并排除问题时，请记住这两步流程。

MoH源

保持呼叫的用户称为保留者，被保持呼叫（并听到MoH）的用户称为保留者。每一方决定播放的音乐的某些方面。

 

音乐源由保持器确定。确定遵循以下层级：

1. 在域名(DN)上配置的音乐源
2. 设备上配置的音乐源
3. 设备配置文件上的音乐源（仅用户保留音乐源）
4. 全局级别的音乐源（服务参数或示例）

有两组音乐源，称为用户保持和网络保持。无论何时引用音乐源，都可能意味着用户保留或网络保留音乐源。

MoH终端

对于MoH，CUCM端的终端是MoH服务器。这一点非常重要，因为编解码器确定（基于区域间编解码器配置）基于：

• MoH服务器区域
• 中继/网关区域

一般建议为MoH服务器分配一个专用区域，以便该区域和所有其他区域之间的区域间编解码器为g.711（或要流出以用于MoH的其他编解码器）。

从CUCM的角度来看，呼叫所涉及的终端不是两部电话，而是：

• 注册到CUCM的IP电话
• 网关/CUBE

因此，CUCM将指向相关网关/CUBE的中继视为终端，并查看与其关联的资源，以确定如何呈现音乐流。

MoH VoIP协议

MoH，按定义，是单向音频对话。信号的发送方式取决于使用的VoIP协议。例如，在SIP上，这通过方向属性传达。在H.323上，CUCM在H.245开放逻辑通道确认(OLCAck)消息中将000000000指定为网络地址，将0指定为MoH服务器的端口(tsapIdentifier)。

注意：对于MMoH，CUCM发送组播地址（例如239.1.1.1）作为网络地址。

在涉及CUBE的呼叫流中，CUCM不了解CUBE和互联网电话服务提供商(ITSP)之间的呼叫段。 CUCM仅关注IP电话和SIP中继（通向CUBE）之间的呼叫段。

MoH信令过程类似于新会话信令过程，范围缩小。例如，在SIP中，会话在已存在的对话的上下文中进行。[1]

禁用媒体流

前面提到的两步流程的第一步是禁用媒体流。

下图说明媒体流如何在SIP中禁用：

 

SIP实施取决于一个属性还是两个属性(?a=?)和？C=IN ?)，以指示媒体流已禁用。

下图说明了H.323中如何禁用媒体流：

  

连接到MoH

前面提到的两步过程的第二步是连接到MoH。禁用音频流后，CUCM向单向MoH会话发出信号，该会话导致被保留者收听MoH源。

在此过程中，CUCM在确定流传输参数之前，会考虑被保留者的媒体功能以及与中继关联的媒体资源组列表(MRGL)。因此，此的信令始终是延迟提供(DO)[2]（在SIP中）。

INVITE事务的实际数量不同。例如，CUCM仅通过一个DO INVITE事务将被保留者连接到MoH。或者，使用DO INVITE来收集持有者的媒体功能，并且使用后续的EO INVITE来将持有者实际连接到MoH。

下图说明SIP的事务：

下图说明H.323的事务：

此图显示了互通环境中的信令消息序列（例如，当CUBE的一端是SIP而另一端是H.323时）：

 

当呼叫中使用媒体资源时

媒体资源(媒体终端点(MTP)/转码器)可屏蔽CUBE到IT服务提供商(ITSP)呼叫段的大部分。当通过CUBE在呼叫中使用媒体资源时，MoH的信令大多涉及CUCM和媒体资源之间的瘦客户端控制协议(SCCP)消息。请注意，处于保持状态的是媒体资源，而不是CUBE中继。在MTP/转码器被发出信号侦听MoH（假设为SIP）后，CUCM将SIP UPDATE消息发送到CUBE。这将更新branch参数，该参数用于标识新事务（MOH会话）。

继续呼叫

恢复过程与暂候过程类似，但订单已撤消：

1. 当前音频流已禁用。
2. 发送另一个DO re-INVITE以将被保留者重新连接到将呼叫置于保留状态的电话。 

SDP属性

为简化集群间中继(ICT)[3]，引入了会话描述协议(SDP)中的X-cisco-media:umoh属性[3]。CUCM使用不同协议的终端之间实现互操作，通常执行不直观的笨拙中间信令。为避免猜测，并使信令上下文显式化，使用名为X-cisco-media的专有SDP属性。

使用CUCM 8.5及更高版本，可以通过将此属性设置为单播通话等待音乐(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将MoH传递给ITSP时的一些问题和问题：

• 组播流量的覆盖范围 — 思科使用239.0.0.0到239.255.255.255范围进行组播音乐。此范围称为管理范围地址。此块被视为专用，这意味着它被企业网络使用，并且不应被转发到企业外部。通常会相应地配置边界路由器。
• VPN组播 — 默认情况下，IP安全不支持MoH。

CUBE支持MoH的方式如下：

1. CUBE从MoH服务器接收MoH数据包。
2. 它将数据包转换为单播IP数据包。
3. CUBE将数据包转发到ITSP。

SIP方向属性操作

如RFC 3264中所述:

“如果会话描述包含的组播媒体流仅列为接收（发送），则意味着参与者（包括提供者和应答者）只能接收（发送）该流。这与单播视图不同，单播视图的方向性是指提供商和应答者之间的介质流。除此说明外，提供的组播流的语义与RFC 2327 [1]中描述的完全相同。”

因此，当CUCM发送带组播IP地址的re-INVITE时，将方向属性设置为recvonly;但是，由于CUBE将组播数据包转换为单播数据包，因此它必须将ITSP的支路上的方向属性设置为sendonly。

下图说明了逻辑：

  

地址处理

在为将ITSP呼叫方连接到MoH源而发送的DO[6] re-INVITE中，CUBE在SIP SDP C=IN字段中发送自己的IP地址。这是单播地址。

此图像提供端到端视图：

 

注意：CUBE必须运行Cisco IOS版本15.2(2)T或更高版本才能支持MoH。 

从闪存流

通过TDM网关，可通过从网关直接流传输组播音乐来节省额外的广域网带宽。因此，如果MoH服务器位于总部，而网关位于通过WAN连接的远程分支机构，则传送MoH的组播流量不必穿过WAN（从总部到分支机构）并使用宝贵的广域网带宽。

CUBE是中继端设备，不能流传输源自本地闪存或通过任何模拟TDM接口的MoH。WAN带宽仍有可能实现。这可以通过在远程分支机构使用另一个支持语音的路由器作为MMoH流的源来实现。此路由器从闪存流MMoH。然后，可以向CUBE发出信号，以接收这些数据包，转换它们，并将它们作为单播数据包传送。

从实时源流

为了从实时源进行流传输，必须配置另一台路由器，因为CUBE不是线路端设备，如前一节所述。

配置MoH

本节介绍如何在支持CUBE、CUCM和L3的交换机上配置MoH。

在CUBE上配置MoH

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

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

在CUCM上配置MoH

要在CUCM上配置MMoH，请执行以下步骤：

1. 在MoH源、MoH服务器和媒体资源组(MRG)上启用组播功能。
2. 将MRGL分配给步骤1中配置的MRG的中继。
3. 在IP语音流应用服务参数中配置编解码器。

注意：有关详细配置步骤，请参阅Cisco Unified Communications System 9.0 SRND — 媒体资源文章中的保留音乐部分。

在支持L3的交换机上配置MoH

在支持L3的交换机上，使用以下命令配置MoH:

ip routing
ip multicast-routing

当呼叫中使用MTP时

MTP不支持组播音乐。被持人只接受死亡。[7]

注意：转码器也是MTP。

性能注意事项

所有MMOH数据包在Cisco IOS中进行进程交换。这对于小型部署来说很合适，但对大型安装的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电话。

首先，确保在问题[5]的SIP中继上未禁用要求SDP非活动交换进行呼叫中媒体更改。这是CUCM在SDP中发送带a=inactive的重新邀请的原因，以中断现有的介质路径。

当呼叫处于保持状态时，如果为SIP中继启用Send-receive SDP in mid-call INVITE复选框，则CUCM不会发送具有非活动SDP的re-INVITE以中断媒体路径[8]。该配置仅在介质模式设置为非活动状态后，对无法提供完整(send-recv)提供的设备进行检查。

以下图片说明了可用的复选框：

注意：有关详细信息，请参阅Cisco Bug ID CSCtx84013。

场景 2

症状 — 呼叫方被置于保持状态而非MoH时，只有提示音。

通常，这表明CUCM未分配MMoH。

• 使用show perf query class? Cisco MOH Device?CUCM CLI命令，以验证MOHOutOfResources计数是否增加。
• 确保在MoH源、服务器和组上启用组播。

场景 3

症状 — 当呼叫者被置于保持状态时，仅听到死气。

请确保：  

• 组播路由在CUBE和音频路径中的其他路由器上启用。
• 在音频路径的第3层交换机上启用IP路由和组播路由。
• CUCM上的MoH服务器上配置了ttl（跳数），其大到足以覆盖跳数。
• 如果需要转码器，则成功分配转码器。
• IP语音流应用上配置的编解码器列表支持用于MoH的编解码器。

场景 4

症状 — 呼叫在呼叫保持和恢复的绕流模式下失败。

为了支持绕流，您必须从IPIPGW发送重新邀请或更新；但是，目前不支持此功能。因此，不支持DO-EO呼叫的流动。如果市场营销中存在此类呼叫流要求，将考虑支持。思科漏洞SIP SIP SS DO-EO:呼叫在呼叫保持和恢复的“绕流”模式下失败，标记为增强功能，以备将来考虑。

相关信息

• Cisco UBE上的组播通话等待音乐支持
• CallManager Music on Hold常见问题
• 技术支持和文档 - Cisco Systems

---

[1]这可能令人困惑 — 您如何在对话中进行不同的对话？在SIP中，对话框是指3-tupe <To tag， From tag， and Call-ID>。此3管在保持阶段保持不变。

[2] DO — 延迟优惠。

[3] 集群间中继线

[4]从CUCM 8.5开始。

[5]在Cisco IOS版本15.3T及更高版本中，代码转换适用于MMoH。 

[6] DO — 延迟提供

[7] 思科统一通信管理器功能和服务指南，版本8.6(1)

[8] 这些是用于配置SIP中继的SIP配置文件上的设置。