Голосовая связь и система унифицированных коммуникаций : Cisco Unified Border Element

MMoH посредством операции CUBE, конфигурации и руководства устранения неполадок

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ описывает операцию, конфигурацию и сведения об устранении проблем для Multicast Music на удержании (MMoH) через Cisco Unified Border Element (CUBE).

Несмотря на то, что фокусом этого документа является Музыка в режиме удержания (MoH) групповой адресации, существенная часть посвящена описанию, как MoH работает в целом. Эти дополнительные сведения помогают создавать основное знание для новичка, чтобы лучше распознать и ценить проблемы, которые являются определенными для MMoH.

Примечание: В то время как принципы - то же, Выпуск Поставщика услуг Унифицированного элемента границы Cisco (SP CUBE) не находится в пределах области этого документа, ни делает использование CUBE в средах, которые не включают Cisco Unified Communications Manager (CUCM).

Внесенный Bakthavatsal Muralidharan, специалистом службы технической поддержки Cisco.

Предварительные условия

Требования 

Для этого документа отсутствуют особые требования.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Общие сведения

Примечание: За исключением нескольких сценариев, которые проиллюстрированы для H.323, сигнализация Протокола SIP используется всюду по большей части этого документа.

Обзор MoH

MoH играется каждый раз, когда абонент размещен на удержании. Когда процесс дополнительного сервиса внедрен, такие как переадресация вызовов или передача, ожидание вызов инициируется или пользователем или сетью. Прежний упоминается, как инициируется пользователями держатсядержатся пользователь, или пользователь держится. Последний является reffered к, как инициируется в сеть держатся, держатся сеть, или сетевое ожидание.

Вот анализ того, как MoH работает с Мультиплексированием с разделением по времени (TDM) шлюзы. Этот образ иллюстрирует компоненты и соединения, вовлеченные в сценарий ожидания вызов:

 

Для заказывания телефонный разговор на удержании, двухэтапный процесс необходим. Этот образ иллюстрирует два включенные шага:

 

Совет: Помните этот двухэтапный процесс, когда вы попытаетесь отсортировать конфигурацию MoH и решить проблемы.

Источники MoH

Пользователь, который заказывает телефонный разговор на удержании, упоминается как держатель, и пользователь, который размещен на удержании (и слышит MoH) упоминается как holdee. Каждая сторона решает определенные аспекты музыки, которая играется.

 

Музыкальный источник определен держателем. Определение придерживается этой иерархии:

  1. Музыкальный источник настроен на Доменном имени (DN)
  2. Музыкальный источник настроен на устройстве
  3. Музыкальный источник на профиле устройства (только источник пользовательской фиксации музыки)
  4. Музыкальный источник на глобальном уровне (параметр сервиса или пример)

Существует два набора музыкальных источников, держатся вызываемый пользователь и держатся сеть. Каждый раз, когда ссылка сделана на музыкальный источник, это могло означать или ожидание пользователь или источник сетевой фиксации музыки.

Оконечные точки MoH

В целях MoH оконечная точка на стороне CUCM является сервером MoH. Это важно для понимания, потому что определение кодека (на основе конфигурации кодека межобласти) основывается:

  • Область сервера MoH
  • Область транка/шлюза

Общий recommedation должен назначить сервер MoH специализированная область, так, чтобы кодек межобласти между той областью и всеми другими областями был g.711 (или другой кодек, который вы хотите передать потоком для MoH).

С точки зрения CUCM оконечные точки, вовлеченные в вызов, не являются двумя телефонами, а скорее:

  • IP-телефон зарегистрировался к CUCM
  • Шлюз/CUBE

Таким образом CUCM обрабатывает транк, который указывает к рассматриваемому шлюзу/CUBE как оконечная точка и изучает ресурсы, привязанные к нему, чтобы определить, как представить музыкальный поток.

Протокол VoIP MoH

MoH, по определению, является диалогом односторонней передачи аудиоданных. То, как это сообщено, зависит от используемого протокола VoIP. Например, на SIP, это передано через атрибут направления. На H.323 CUCM задает 00000000 как сетевой адрес и 0 как порт (tsapIdentifier) сервера MoH в H.245 Открытый Ack Логического канала (OLCAck) сообщение.

Примечание: Для MMoH CUCM передает адрес групповой адресации (239.1.1.1, например) как сетевой адрес.

В диаграммах вызовов, которые включают CUBE, CUCM не имеет никакого знания об участке вызова между CUBE и Поставщиком услуг интернет-телефонии (ITSP). CUCM только касается участка вызова между IP-телефоном и магистралью SIP (приводящий к CUBE).

Процесс сигнализации для MoH подобен сигнализации для нового диалога с уменьшенной областью. В SIP, например, диалог имеет место в контексте диалога, который уже существует. [1]

Отключите поток мультимедиа

Первый шаг в ранее упомянутом двухэтапном процессе должен отключить поток мультимедиа.

Этот образ иллюстрирует, как поток мультимедиа отключен в SIP:

 

Реализации SIP варьируются относительно или один или оба атрибута (? =? и? C=IN?) используются, чтобы указать, что отключен поток мультимедиа.

Этот образ иллюстрирует, как поток мультимедиа отключен в H.323:

  

Соединитесь с MoH

Действие второе в ранее упомянутом двухэтапном процессе должно соединиться с MoH. Как только аудиопоток отключен, CUCM сигнализирует односторонний диалог MoH, который заставляет holdee слушать источник MoH.

Как часть этого процесса, CUCM принимает во внимание возможности сред holdee и Списка Media Resource Groups (MRGL), привязанного к транку, прежде чем это определит параметры для потоковой передачи. Соответственно, сигнализация для этого всегда является Задержанным предложением (DO) [2] (в SIP).

Фактическое количество транзакций INVITE варьируется. Например, CUCM подключает holdee с MoH только с, каждый делает транзакцию INVITE. Также делают INVITE, используется для сбора возможностей сред holdee, и последующий INVITE EO используется для фактического соединения holdee с MoH.

Этот образ иллюстрирует транзакцию для SIP:

Этот образ иллюстрирует транзакцию для H.323:

Этот образ иллюстрирует последовательность сообщения о передаче сигнала во взаимодействующей среде (когда одна сторона CUBE является SIP и другим H.323 стороны, например):

 

Когда Медиаресурсы Используются в Вызове

Медиаресурсы (Точка MediaTermination (MTP) / перекодировщики) экранируют CUBE К ПОСТАВЩИКУ ИТ-УСЛУГ (ITSP) участок вызова по большей части. Когда медиаресурс используется в вызове через CUBE, сигнализирующий для MoH главным образом включает сообщения Skinny Client Control Protocol (SCCP) между CUCM и Медиаресурсом. Заметьте, что это - медиаресурс, который приостановлен, не транк CUBE. После того, как MTP/Перекодировщик сообщен для слушания MoH (принимающий SIP), CUCM передает Обновленное сообщение SIP к CUBE. Это обновляет параметр ответвления, который определяет новую транзакцию (диалог MOH).

Возобновите вызов

Процесс резюме подобен процессу ожидания, за исключением того, что инвертирован заказ:

  1. Текущий аудиопоток отключен.
  2. Другой делает переINVITE, передается, чтобы повторно подключить holdee с телефоном, который разместил удержанный вызов. 

Атрибут SDP

Атрибут X-cisco-media:umoh в Протоколе описания сеанса (SDP) был представлен для упрощения MoH, сигнализирующего по Межкластерным магистралям (ICT) [3]. Со взаимодействием между оконечными точками, которые используют другие протоколы, CUCM часто выполняет неловкую и промежуточную сигнализацию, которая неинтуитивна. Во избежание догадок, и делают сигнализацию явной контекстом, составляющий собственность атрибут SDP, названный X-медиа-Cisco, используется.

С Версиями CUCM 8.5 и позже, MoH может [4] быть сообщенным с этим набором атрибута или к Музыке индивидуальной рассылки в ожидании (UMoH) или к MMoH, который удаляет уверенность в поддельном значении порта для указания на сценарий MoH проведенной стороне.

Примечание: Это не влияет на MoH, сигнализирующий с CUBE.

MoH на CUBE

С CUBE основной процесс остается тем же; однако, важно полагать, что [5] CUBE не транскодирует MoH до Cisco Версия 15.3T IOS�. Это означает, что необходимо быть осторожными с факторами, которые влияют на выбор кодека на участке CUCM к CUBE так, чтобы не был необходим перекодировщик.

Примечание: Перекодировщик, на который ссылаются здесь, вставлен CUBE (в противоположность CUCM). Насколько CUCM затронут, CUBE является назначением, и это не вовлекает перекодировщика в путь moh server к CUBE.

Факторы кодека

В целом несколько факторов влияют на кодек, используемый на участке CUCM к CUBE, но эти факторы просят MoH:

  • MoH не может быть транскодирован. [5]
  • MoH звучит хорошим только с G.711.

Примечание: Эта тема выходит за рамки этого документа, потому что много хороших документов уже существуют на факторах кодека, и это было бы избыточно для покрытия его здесь.

MMoH

Примечание: Большая часть информации, описанной в этом документе к настоящему времени, релевантна, передан ли MoH потоком с пакетами IP-адреса групповой адресации или индивидуальной рассылкой.

MMoH сохраняет ресурсы системы и пропускную способность. Групповая адресация позволяет нескольким пользователей использовать тот же поток источника звука для обеспечения музыки на удержании. MMoH выбираем в любой корпоративной сети, где экономия полосы пропускания важна.

Когда CUBE передает MMoH по Интернету к ITSP, вот некоторые проблемы и проблемы:

  • Достигните многоадресного трафика - Cisco использует диапазон 239.0.0.0 для 239.255.255.255 для музыки групповой адресации. Этот диапазон известен как административно адреса областей действия. Этот блок считают частным, что означает, что он используется корпоративными сетями и никогда не должен передаваться за пределами предприятия. Граничные маршрутизаторы обычно настраиваются соответственно.
  • Групповая адресация по VPN - По умолчанию, IP-безопасность не поддерживает MMoH.

Это - то, как CUBE поддерживает MMoH:

  1. CUBE получает пакеты MMoH от сервера MoH.
  2. Это преобразовывает пакеты в пакеты IP индивидуальной рассылки.
  3. CUBE передает пакеты к ITSP.

Манипулирование атрибутом направления SIP

Как описано в RFC 3264:

"Если описание сеанса содержит поток мультимедиа групповой адресации, который перечислен, как получают (передают) только, это означает, что участники, включая оферента и отвечающую сторону, могут только получить (передают) на том потоке. Это отличается от представления индивидуальной рассылки, где направленность обращается к потоку сред между оферентом и отвечающей стороной. Кроме того разъяснение, семантика предлагаемой многоадресной рассылки точно как описана в RFC 2327 [1]"

Соответственно, когда CUCM передает переINVITE с IP-адресом групповой адресации, он устанавливает атрибут направления в recvonly; однако, так как CUBE преобразовывает пакеты групповой адресации в одноадресные пакеты, он должен установить атрибут направления в sendonly на участке с ITSP.

Этот образ иллюстрирует логику:

  

Манипулирование адресом

В [6] переINVITE, передаваемый для соединения абонента ITSP с источником MoH, CUBE передает собственный IP-адрес в поле SIP SDP C=IN. Это - одиночный адрес.

Этот образ предоставляет сквозной просмотр:

 

Примечание: CUBE должен выполнить версию Cisco IOS 15.2 (2) T или позже для поддержки MMoH. 

Поток от Флэша

Со шлюзами TDM дополнительные сохранения полосы пропускания глобальной сети (WAN) поняты путем потоковой передачи музыки групповой адресации прямо от шлюза. Таким образом, если сервер MoH в главном офисе, и шлюз при удаленном ответвлении по подключению к глобальной сети (WAN), многоадресный трафик, который переносит MoH, не должен пересекать глобальную сеть (WAN) (от главного офиса до ответвления) и использовать ценную полосу пропускания глобальной сети (WAN).

CUBE является устройством транковой стороны, которое не способно к потоковой передаче MMoH, который получен от локальной флэш-памяти или через любой аналоговый интерфейс TDM. Все еще возможно понять полосу пропускания глобальной сети (WAN). Это выполнено с использованием другого с поддержкой голоса маршрутизатор при удаленном ответвлении как источник потока MMoH. Этот маршрутизатор потоки MMoH от флэш-памяти. CUBE может тогда быть сообщен, чтобы получить те пакеты, преобразовать их и передать их как одноадресные пакеты.

Поток от Оперативного Канала

Для потоковой передачи от оперативного канала другой маршрутизатор должен быть настроен, потому что CUBE не является устройством стороны канала, как обсуждено в предыдущем разделе.

Настройте MMoH

В этом разделе описываются как к configue MMoH на CUBE, CUCM и способных к L3 коммутаторах.


Настройте MMoH на CUBE

Используйте эти команды для настройки MMoH на CUBE:

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

Настройте MMoH на CUCM

Выполните эти действия для настройки MMoH на CUCM:

  1. Включите возможность групповой адресации на источнике MoH, сервере MoH и Media Resource Groups (MRG).
  2. Назначьте MRGL на транк с MRG, настроенным в шаге 1.
  3. Настройте кодек в параметрах сервиса речевой программы речевой связи IP.

Примечание: Обратитесь к Музыке в ожидании раздел статьи Cisco Unified Communications System 9.0 SRND - Media Resources для шагов подробной конфигурации.

Настройте MMoH на способных к L3 коммутаторах

Используйте эти команды для настройки MMoH на способных к L3 коммутаторах:

ip routing
ip multicast-routing

Когда MTP Используется в Вызове

MTP не поддерживают музыку групповой адресации. holdee получает только тишину в эфире. [7]

Примечание: Перекодировщики являются MTP также.

Вопросы производительности

Все пакеты MMOH являются процессом, коммутированным в Cisco IOS. Это хорошо для небольшие развертывания, но оказывает значительное влияние на производительность CUBE для больших установок.

Ограничения

Вот список ограничений с использованием MMoH:

  • CUBE должен быть в версии Cisco IOS 15.2 (2) T или позже.
  • MMoH не поддерживается на AS54xx.
  • MMoH не поддерживается на ISR-G1s (28xx, 38xx серия)
  • Знайте о кодеках, которые поддерживаются.

Устранение неполадок

Используйте этот раздел для устранения проблем MMoH. 

Команды show и debug

Вот список показа и команд отладки и их значений:

  • Музыка show ccm-manager - Помогает подтверждать, что 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 
  • Участники igmp show ip - Используемый, чтобы проверить, присоединился ли 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
  • Покажите класс запроса перфекта "Устройство MOH Cisco" - Эта команда CLI CUCM используется, чтобы быстро проверить, выделен ли Ресурс 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 - Эта команда используется, чтобы отследить, как участки вызова изменены (когда вы отключаете текущее аудио и MoH подключения, например), а также проверьте, присоединяется ли CUBE к группе Протокола IGMP, как проинструктировано CUCM.
  • Debug ip packet - Эта команда используется в качестве альтернативы Wireshark для проверок. Однако эта команда может быстро сокрушить ЦПУ. Используйте его только когда абсолютно необходимый; выключите вход через консоль и не выполняйте его для больше, чем секунда.

Сценарий 1

Признак - вызов от Открытой коммутируемой телефонной сети (PSTN) устанавливает прекрасный с двухсторонним аудио. Однако, когда IP-телефон размещает Вызывающего абонент PSTN на удержании и затем возобновляет вызов, результаты односторонней передачи аудиоданных: IP-телефон слышит аудио от PSTN, но пользователь PSTN не может услышать IP-телефон.

Во-первых, удостоверьтесь, что Требуют SDP, Неактивный Exchange для Середины Изменения Сред Вызова НЕ отключен на рассматриваемой магистрали SIP [5]. Это - то, что позволяет CUCM передать переINVITE с a=inactive в SDP для ломки коммуникационного тракта, который существует.

То, когда вызов помещен на удержании, CUCM не передает переINVITE с неактивным SDP для ломки коммуникационного тракта, если Передача передает - получают SDP в середине флажка INVITE вызова, включено для магистрали SIP [8]. Та конфигурация проверена только для устройств, которые не могут предоставить полное (передавать-recv) предложение после того, как режим сред установлен в неактивный.

Вот образы, которые иллюстрируют доступные флажки:

Примечание: Обратитесь к идентификатору ошибки Cisco CSCtx84013 для дополнительных сведений.

Сценарий 2

Когда абоненты размещены на удержании вместо MMoH, признак - существует только тон.

Обычно это предполагает, что CUCM не выделял MMoH.

  • Использовать класс запроса перфекта показа? Устройство MOH Cisco? Команда CLI CUCM, чтобы проверить, считают ли MOHOutOfResources инкременты.
  • Гарантируйте, что передает в многоадресном режиме, включен на источнике MMoH, сервере и группе.

Сценарий 3

Когда абонент размещен на удержании, признак - Только тишину в эфире слышат.

Убедитесь в следующем:  

  • Multicast-routing включен на CUBE и других маршрутизаторах в аудиопути.
  • IP routing и multicast-routing включены на коммутаторах L3 в аудиопути.
  • ТТЛ-схема (счетчик переходов) настроена на сервере MoH на CUCM и достаточно большая для покрытия переходов.
  • Если перекодировщик требуется, он выделен успешно.
  • Список кодеков, настроенных на Речевой Программе речевой связи IP, поддерживает кодек, используемый для MoH.

Сценарий 4

Признак - сбои вызова в потоке - вокруг режима для Вызова держатся и Резюме.

Для поддержки потока - вокруг, необходимо передать переINVITE или обновление от IPIPGW; однако, это в настоящее время не поддерживается. Следовательно, поток - вокруг с делает - EO, вызовы не поддерживается. Если будет такое требование потока вызовов от маркетинга, то рассмотрение для поддержки будет сделано. Ошибка Cisco, SIP SIP SS делают - EO: Звоните сбои в Потоке вокруг режима для Вызова держатся и Резюме, отмечен как усовершенствование для рассмотрения в будущем.

Дополнительные сведения



[1] Это может сбить с толку - Как у вас может быть другой диалог в диалоге? Ну, в SIP диалог обращается к 3-tupe <Для маркировки От метки и CallId>. Это 3-tupe остается тем же во время фазы ожидания.

[2] Сделайте - задержанное предложение.

[3] Межкластерная магистраль

[4] Начало с CUCM 8.5.

[5] Перекодировка работает для MMoH в версиях Cisco IOS 15.3T и позже. 

[6] Сделайте - задержанное предложение

[7] Функции Cisco Unified Communications Manager и руководство по службам, выпуск 8.6 (1)

[8] Это параметры настройки на профиле SIP, используемом для настройки магистрали SIP.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 116392