语音和统一通信 : Cisco Unified Border Element

MMoH通过多维数据集操作,配置,和排除故障指南

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 23 日) | 反馈

简介

本文通过Cisco Unified Border Element (多维数据集)描述操作、配置和故障排除信息组播音乐的(MMoH)。

虽然本文焦点是组播音乐(MoH),一个大量的部分专用于描述MoH如何一般来说运作。此其他信息帮助构建初学者的一BASE知识为了改善认可并且赞赏是特定对MMoH的问题。

注意:当原理是同样时, Cisco Unified博德元素服务供应商版本(CUBE-SP)在本文的范围内,不落,亦不求在不涉及Cisco Unified Communications Manager的环境的使用情况的立方(CUCM)。

贡献用Bakthavatsal Muralidharan, Cisco TAC工程师。

先决条件

要求 

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

使用的组件

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

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

背景

注意:除为H.323说明的两三个方案外,会话初始化协议(SIP)发信号使用在大多数本文中。

MoH概述

MoH播放,每当呼叫方被放置的保持。呼叫保持启动由用户或通过网络,当附加服务进程实现时,例如呼叫转发或转移。前面指用户启动的暂挂用户保留或者用户保留。后者指网络初始化暂挂网络保留或者网络保留

这是回顾MoH如何与Time Division Multiplexing (TDM)网关一起使用。此镜像说明在呼叫保持方案和连接涉及的组件:

 

为了发出保持的呼叫,两步过程是需要的。 此镜像说明包括的两个步骤:

 

提示:当您尝试通过MoH配置排序和排除故障问题时,请切记此两步过程。

MoH来源

发出保持的呼叫的用户指持有人和被放置的保持的用户(和听到MoH)指holdee。 每侧决定播放音乐的某些方面。

 

持有人取决于音乐来源。确定跟随此层级:

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

有两套音乐来源,呼叫用户保留和网络保留。每当参考做给音乐来源,可能含义用户保留或网络保留音乐来源。

MoH终端

对于MoH目的,在CUCM侧的终端是MoH服务器。这是重要了解,因为编码确定(根据相互赤道区编码配置)根据:

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

一般recommedation是分配MoH服务器一个专用的区域,因此在该区域和其他地区之间的相互赤道区编码是您希望为MoH放出)的g.711 (或其他编码。

从CUCM方面,在呼叫涉及的终端不是两个电话,但是相当:

  • IP电话注册对CUCM
  • gateway/CUBE

因此, CUCM对待指向gateway/CUBE有问题的作为终端的中继,并且调查资源关联与它为了确定如何回报音乐数据流。

MoH VoIP协议

MoH,根据定义,是单向音频会话。如何发信号取决于使用的VoIP协议。例如,在SIP,这通过方向属性被转达。在H.323, CUCM指定00000000作为网络地址和0作为端口(tsapIdentifier)在H.245开放逻辑信道Ack (OLCAck)消息的MoH服务器。

注意:对于MMoH, CUCM发送组播地址(例如239.1.1.1)作为网络地址。

在介入多维数据集的呼叫流, CUCM没有关于呼叫段的知识在多维数据集和互联网电话服务提供商(ITSP)之间。CUCM只于在IP电话和SIP中继之间的呼叫段有关(导致求立方)。

信令进程MoH的类似于发信号一次新的会话的,与减少的范围。在SIP中,例如,会话在已经存在.[1]的对话的上下文内发生

禁用媒体流

在以前被提及的两步过程的第一步将禁用媒体流。

此镜像说明媒体流如何在SIP:禁用

 

SIP实施变化至于是否一个或两个属性(?a= ?并且?C=IN ?)用于为了表明媒体流禁用。

此镜像说明媒体流如何在H.323禁用:

  

对MoH的连接

在以前被提及的两步过程的第二步将连接对MoH。一旦音频流禁用, CUCM发信号造成holdee听MoH来源的单程MoH会话。

作为此进程一部分, CUCM考虑到用中继和Media Resource Group List (MRGL)的关联的媒介功能holdee,在确定放出的前参数。相应地,发信号此的总是延迟的提供() [2] (在SIP)。

INVITE处理实际数量变化。例如, CUCM连接holdee对与一个的MoH邀请处理。或者,请执行INVITE使用为了采集holdee的媒介功能,并且随后的EO INVITE用于为了实际上连接holdee到MoH。

此镜像说明SIP:的处理

此镜像说明H.323的处理:

此镜像说明在相互作用环境的信令消息顺序(当多维数据集一端是SIP和另一侧H.323时,例如) :

 

当梅迪亚资源用于呼叫

梅迪亚资源(MediaTermination点(MTP)/代码转换器)屏蔽材料多维数据集对IT服务提供商(ITSP)呼叫段至于大部分。当媒体资源用于一呼叫通过多维数据集时,发信号MoH的主要介入在CUCM和梅迪亚资源之间的小型客户机控制协议(SCCP)消息。注意它是留在的媒体资源,不是多维数据集中继。在MTP/transcoder发信号听MoH (假设SIP)后, CUCM传送SIP更新消息求立方。这更新分支参数,识别新的处理(MOH会话)。

恢复呼叫

恢复进程类似于暂挂进程,除了命令被倒转:

  1. 当前音频流禁用。
  2. 别的执行再邀请发送为了重新连接holdee到发出保持的呼叫的电话。 

SDP属性

X思科梅迪亚:在会话描述协议(SDP)的umoh属性介绍为了简化在集群间中继线(ICT) [3]的Moh信令。使用在使用不同的协议的终端之间的配合动作, CUCM经常执行无直觉的笨拙和半成品信令。为了避免猜测和使信令上下文明确,已命名X思科梅迪亚,使用一个所有权SDP属性。

使用CUCM版本8.5和以上, MoH可能[4]发信号此属性设置为单播Music on Hold (UMoH)MMoH,取消对一个假端口值的信赖指示MoH方案到保持Party。

注意:这不影响与多维数据集的Moh信令。

在多维数据集的MoH

使用多维数据集,基本流程依然是同样;然而,考虑是重要的[5]多维数据集不转码直到Cisco IOS 版本15.3T的MoH。这意味着您一定小心对影响在CUCM对多维数据集段的编码选择的要素,以便代码转换器不是需要的。

注意:被参考的代码转换器此处由多维数据集插入(与CUCM相对)。就CUCM而言,多维数据集是目的地,并且不在MOH服务器对多维数据集路径介入任何代码转换器。

编码考虑事项

一般来说,几个要素影响用于CUCM对多维数据集段的编码,但是这些考虑事项申请MoH :

  • MoH不可能转码。[5]
  • MoH声音仅好与G.711。

注意:此主题是在本文的范围之外,因为许多好文档在编码考虑事项已经存在,并且冗余包括它此处。

MMoH

注意:在本文描述的大多数信息至今是相关的MoH是否用单播或组播IP数据包放出。

MMoH保存系统资源和带宽。组播允许多个用户使用同一音频来源数据流为了提供音乐。MMoH是理想在带宽节省量是重要的所有公司网络。

这是一些注意事项和问题,当多维数据集通过在互联网的MMoH对ITSP时:

  • 伸手可及的距离组播数据流-思科使用范围239.0.0.0对239.255.255.255组播音乐。此范围叫作管理性scoped地址。此块被认为私有,因此意味着企业网络使用,并且应该从未转发在企业外面。边界路由器相应地通常配置。
  • 在VPN的组播-默认情况下, IP安全不支持MMoH。

这是多维数据集如何支持MMoH :

  1. 多维数据集收到从MoH服务器的MMoH数据包。
  2. 它转换数据包到单播IP信息包。
  3. 多维数据集转发数据包对ITSP。

SIP方向属性处理

正如RFC 3264所描述

“如果只列出作为接收的会话说明包含组播媒体流(发送),意味着参加者,包括发货人和回答者,在该数据流能只接收(发送)。这与单播视图有所不同,定向性是指媒体流在发货人和回答者之间。在该说明之外,提供的组播流的语义正确地是正如RFC 2327 [1]"所描述

相应地,当CUCM发送与组播IP地址时的一再邀请,它设置方向属性为recvonly;然而,因为多维数据集转换组播信息包到单播信息包,它必须设置方向属性为在段的sendonly有ITSP的。

此镜像说明逻辑:

  

地址处理

DO[6]发送的再邀请中为了联络ITSP呼叫方到MoH来源,多维数据集在SIP SDP C=IN字段发送其自己的IP地址。这是单播地址。

此镜像提供端到端视图:

 

注意:多维数据集必须运行Cisco IOS版本15.2(2)T或以上为了支持MMoH。 

从闪存的数据流

使用TDM网关,另外的WAN带宽储蓄通过放出从网关的组播音乐认识到。因此,如果MoH服务器在总部和网关在WAN连接间的一远程分支机构,运载MoH不必须横断广域网的组播数据流(从分组的总部)和使用重要的WAN带宽。

多维数据集是不能够放出MMoH来源从本地闪存或通过所有模拟TDM接口的中继线侧设备。认识到WAN带宽是可能的。这用使用在远程分支机构的另一个支持语音的路由器完成作为MMoH数据流的来源。此路由器放出从闪存的MMoH。多维数据集可能然后发信号为了收到那些数据包,转换他们和通过他们作为单播信息包。

从Live源的数据流

为了从Live源放出,必须配置另一个路由器,因为多维数据集不是一个线路侧设备,如前面部分所述。

配置MMoH

此部分描述如何配置在多维数据集、CUCM和L3-capable交换机的MMoH。


配置在多维数据集的MMoH

请使用这些命令为了配置在多维数据集的MMoH :

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

配置在CUCM的MMoH

遵从这些步骤为了配置在CUCM的MMoH :

  1. 启用在MoH来源、MoH服务器和梅迪亚资源组(MRG)的组播功能。
  2. 分配MRGL到有在step1配置的MRG的中继。
  3. 配置在IP语音流应用服务参数的编码。

注意:参考思科统一通信系统9.0 SRND的Music on Hold部分-梅迪亚资源条款关于详细配置步骤。

配置在L3-Capable交换机的MMoH

请使用这些命令为了配置在L3-capable交换机的MMoH :

ip routing
ip multicast-routing

当MTP用于呼叫

MTPs不支持组播音乐。holdee只接收停止air.[7]

注意:代码转换器也是MTPs。

性能注意事项

所有MMOH数据包是在Cisco IOS交换的进程。可以没关系为小部署,但是有在多维数据集性能的一个重大影响较大规模的安装的。

限制

这是限制列表与使用的MMoH :

  • 多维数据集必须在Cisco IOS版本15.2(2)T或以上。
  • AS54xx不支持MMoH。
  • ISR-G1s (28xx不支持MMoH, 38xx系列)
  • 注意支持的编码。

故障排除

请使用此部分为了排除故障MMoH。 

show 与 debug 命令

这是列表显示和调试指令和他们的含义:

  • Show ccm-manager音乐-帮助确认多维数据集在哪里知道细听组播音乐数据包,并且它是否接收他们。
    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 
  • 显示ip igmp成员-用于为了检查多维数据集是否顺利地加入组播组,当发信号侦听组播音乐。

  • 这三命令用于为了检查终端的经过协商的编码、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摘要问题此命令,当呼叫是保持为了检查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
  • 显示穿孔机查询类“Cisco MOH设备” - CLI命令此的CUCM用于为了迅速检查是否分配MOH资源,并且什么种类(单播或组播)。此命令不是有用的,当您有多个呼叫NO-保持时,作为动态计数更改,当呼叫留在并且恢复时。
    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音乐-此命令用于为了追踪呼叫段如何更改(当您禁用当前音频并且连接MoH时,例如),以及验证多维数据集是否参加互联网组管理协议(IGMP)组如提示由CUCM。
  • 调试ip数据包-此命令使用作为对Wireshark的一替代方案检查。然而,此命令能迅速淹没CPU。请使用它,只有当绝对必要;比一秒钟关闭控制台记录和请勿为更多运行它。

场景 1

症状-从公共交换电话网(PSTN)的一呼叫优良设立与双向音频。然而,当IP电话放置保持的PSTN主叫方然后恢复呼叫时,单向音频发生:IP电话听到从PSTN的音频,但是PSTN用户不能听到IP电话。

首先,请确保请要求SDP MID呼叫的崔凡吉莱question[5]的SIP中继没有禁用的梅迪亚非激活Exchange。这是什么使CUCM发送与a=inactive的一再邀请在SDP,为了中断存在的媒体路径。

当呼叫留在时, CUCM不发送一再邀请以非激活SDP为了中断媒体路径,如果在MID呼叫的发送收发SDP邀请复选框为SIP trunk[8]启用。该配置仅被检查不能提供一次全双工的设备(发送RECV)提供,在媒体模式设置对非激活后。

这是说明可用的复选框的镜像:

注意:其他信息的参考的Cisco Bug ID CSCtx84013。

场景 2

症状-,当呼叫方被放置的保持而不是MMoH时,有仅音。

通常,这建议CUCM没有分配MMoH。

  • 请使用显示穿孔机查询类?思科MOH设备?CLI命令的CUCM为了验证,如果MOHOutOfResources计数增加。
  • 保证组播在MMoH来源、服务器和组启用。

场景 3

症状-,当呼叫方被放置的保持时,仅断线听到。

请确保:  

  • 组播路由在多维数据集和其他路由器启用在音频路径。
  • IP路由和组播路由在L3交换机启用在音频路径。
  • ttl (跳数)在CUCM的MoH服务器配置,并且是足够大覆盖跳。
  • 如果代码转换器要求,成功分配。
  • 在IP语音流应用程序配置的编码列表支持用于MoH的编码。

场景 4

症状-呼叫失效流在呼叫暂挂&恢复的模式附近。

为了支持流在附近,您必须发送一再邀请或一次更新从IPIPGW;然而,当前不支持这。因此,流在与DO-EO呼叫附近不支持。如果有从营销的这样一个呼叫流需求,支持的一考虑事项将做。Cisco Bug, SIP SIP SS DO-EO :呼叫失效在模式附近的流呼叫暂挂的&恢复,在将来被标记作为考虑事项的一增强。

相关信息



[1]这可以是混乱如何能您有在对话内的一次不同的会话?那么,在SIP,对话是指3-tupe <To标记,从标记和Call-ID>。在暂挂相位期间,此3-tupe保持同样。

[2] -延迟的提供。

[3]集群间中继线

从CUCM 8.5开始的[4]

[5]转码为在Cisco IOS版本15.3T的MMoH工作和以后。 

[6] -延迟的提供

[7] Cisco Unified Communications Manager功能和服务指南,版本8.6(1)

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


相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


Document ID: 116392