Если сравнивать Multicast MoH и Unicast MoH, безусловно технология мультикаста имеет преимущество, поскольку позволяет обходиться одним потоком для нескольких абонентов и тем самым экономить сетевые ресурсы. Это особенно актуально для филиалов компании, подключенных через медленные WAN. При использовании централизованной топологии сервера MoH располагаются в центральном узле, - в этом случае юникастный MoH потребует для каждого абонента поставленного на Hold, по отдельному потоку. Multicast MoH будет использовать лишь один поток для всех абонентов.

На данном ресурсе имеются несколько статей, посвящённых тематике MoH или Music on Hold:

• Music On Hold: Unicast MoH
• Multicast MoH: Что такое Multicast
• Настройка Multicast MoH

Данная статья вытекает из предыдущей части Настройка Multicast MoH, с которой настоятельно рекомендуется ознакомиться. Там мы настроили работу "стандарного" Multicast MoH, при котором CUCM генерит поток мультикаста. Мы настроили оборудование специальным образом для работы Multicast, в том числе и для прохождения Multicast через туннель GRE. В результате поток "честно" проходит через туннель WAN и в итоге попадает на региональный телефон.

Multicast MOH Server на маршрутизаторах филиалов или Multicast MOH from branch router fiash позволяет нам пойти дальше. Мы можем настроить в каждом филиале свой сервер MoH, и больше не будет нужды гонять музыку по узким WAN-каналам.

Multicast MOH from branch router fiash работает только с Multicast MoH.
Общий смысл работы заключается в том, что Cisco IOS SRST gateway можно настроить как сервер Multicast MoH, и он будет непрерывно отдавать поток MoH, причем независимо от того в каком режиме работает сама служба SRST: standby mode или fallback mode.

Настройки CUCM и телефонов остаются такими же , как и для работы "обычного" Multicast MoH, единственная разница в том, что мы перекроем поток от CUCM к телефону и подставим вместо него поток от локального Cisco IOS SRST gateway. В результате телефон будет думать что поток идет от CUCM, тогда как на самом деле это будет поток от локального маршрутизатора.

Работа Multicast MOH from branch router fiash

Давайте посмотрим что будет происходить, если в данной схеме Tel1 поставит на ожидание Tel3:

• В соответствии с VGK_mrgl, для удалённого телефона в качестве media resource for MOH будет выбран CUCM.
• Cisco Unified Communications Manager даёт приказ телефону принимать MoH на адрес (группу) 239.1.1.1, порт 16384.
• Cisco Unified Communications Manager отдаёт поток MoH на адрес (группу) 239.1.1.1, порт 16384.
• Маршрутизатор в центральном офисе дропит пакеты мультикаста и не даёт им зайти в туннель.
• Маршрутизатор удалённого филиала настроен как SRST Gateway. В его конфигурации SRST также включен Multicast MoH c аналогичными параметрами, т.е. адрес (группа) 239.1.1.1, порт 16384. В результате этот маршрутизатор непрерывно отдаёт поток мультикаста в сеть.
• IP телефон принимает "подставной" поток мультикаста от своего SRST Gateway и проигрывает его.

Итак, как уже было сказано выше Multicast MOH from branch router fiash работает только с Multicast MoH. Это означает, что для работы нам нужно будет настроить на CUCM Multicast MoH вместо дефолтного Unicast-а.

Каждый SRST Gateway или Cisco Unified Communications Manager Express может поддерживать до 6-ти MoH Files. Следовательно для каждого филиала может быть настроено до 6-ти Audio Sources.

Кодек G.711

SRST Gateway или CUCME поддерживают только кодек G.711, поэтому и мультикастный MoH на CUCM должен настраиваться на G.711.
Для того чтобы гарантировать использование кодека G.711 для работы MoH на всех регионах, мы сделаем специальную настройку в CUCM.
Подробно это описано в статье Настройка Multicast MoH, раздел "Используемый кодек для MOH".
Идея следующая:

• Помещаем Cisco Unified Communications Manager MOH server в отдельный регион, например Moscow_MOH_SRV_region.
• Помещаем все устройства филиалов в свои регионы. В нашем примере это vgk_region
• В настройках регионов разрешаем G.711 между Moscow_MOH_SRV_region и vgk_region
• В настройках vgk_region мы можем внести ограничение на G.729 для других регионов, но это не повлияет на кодек для MoH.

Перекрытие Multicast

Как уже упоминалось, для того чтобы не допустить распространение Multicast через WAN-линки, мы его должны искусственно перекрыть.
Остановку Multicast производят на центральном пограничном маршрутизаторе. В нашем случае это msk01gtw01.
Существует несколько способов перекрытия потока Multicast:

• Установка Time To Live (TTL) на достаточно небольшое значение, которого будет хватать чтобы играли телефоны центрального офиса, и не хватало на "переваливание" в туннель. TTL устанавливается в настройках MOH Server, параметр Max Hops, см.Настройка Multicast MoH, раздел "Шаг 4:Настройка MOH Server". Понятно, что не во всех сетях будет сподручно использовать данный метод, но конкретно в нашем примере топология позволяет его реализовать: достаточно установить Max Hops=2.
• Фильтрация пакетов Multicast через использование IP access control list (ACL). Пожалуй наиболее универсальный метод. В нашем примере на туннельном интерфейсе msk01gtw01 можно сделать что-то вроде:
  

  ip access-list extended moh_multicast_drop_acl
   deny   ip host 192.168.0.11 239.1.1.0 0.0.0.255
   deny   ip host 192.168.0.12 239.1.2.0 0.0.0.255
   permit ip any any
  
  interface Tunnel6
   ip address 172.16.100.9 255.255.255.252
   ip access-group moh_multicast_drop_acl out
   ip pim sparse-mode
   ip ospf network point-to-point
   tunnel source 62.121.69.157
   tunnel destination 54.205.149.228

• Выключение поддержки Multicast на туннельном интерфейсе. Все просто: тупо выключаем no ip pim sparse-mode и никаго мультикаста!

Настройка

Как уже упоминалось, для настройки работы Multicast MOH Server на маршрутизаторах филиалов, мы сперва должны выполнить все пункты в статье Настройка Multicast MoH, т.е. фактически мы должны добиться чтобы у нас успешно работала стандартная имплементация Multicast.

Далее нам останется выполнить следующие шаги:

Настройка: Перекрытие Multicast

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

Настройка: Включение Multicast MOH на Cisco IOS SRST gateway

В случае в SRST конфигурация будет следующей:

call-manager-fallback
 max-conferences 8 gain -6
 transfer-system full-consult
 ip source-address 192.168.210.1 port 2000
 max-ephones 50
 max-dn 50 dual-line
 system message primary SRST Mode
 moh "SampleAudioSource.ulaw01.wav"
 multicast moh 239.1.1.1 port 16384
 time-zone 40
 time-format 24
 date-format dd-mm-yy
!
voice moh-group 2
moh SampleAudioSource.ulaw02.wav
description MOH Server2
multicast moh 239.1.2.1 port 16384

Здесь файл MoH может быть с расширением .wav или .au и в формате 8-bit 8 kHz data, т.е. a-law или u-law.
Самое простое - вытащить файл из бэкапа CUCM. Там есть архив с именем типа 2013-12-02-17-01-14_CUCM01_CCM_MOH.tar внутри него достать файл SampleAudioSource.ulaw.wav это как раз нужный нам формат.
Далее файлик можно переименовать так как нам удобно.
В случае, если в кластере два физических сервера CUCM, и значит два сервера MoH, нам потребуется организовать два потока. Мы создадим второй поток используя moh-group 2.

Проверить настройки SRST, в том числе и настройки MoH, мы можем через команду:
show call-manager-fallback