Медиасервер предназначен для прокcирования речевой и видео-информации по протоколу RTP, организации конференций, записи разговоров, воспроизведения медиафайлов и различных комбинаций этих режимов.

Управление ресурсами медиасервера осуществляется с помощью механизма control channel (RFC 6230 Media Control Channel Framework, RFC 6231 IVR Control Package, RFC 6505 Mixer Control Package).

Описание медиасервера

Функционал, выполняемый на медиасервере

1. После инсталляции медиасервер запускается с начальными установками, заданными на этапе инсталляции.
2. Во время запуска на медиасервере стартует процесс, который определяет список доступных в системе сетевых интерфейсов. На основании этого списка формируется список UA для регистрации на SIP-сервере.
3. По известному списку UA осуществляется регистрация этих UA на SIP-сервере. Сообщения SIP REGISTER отправляются для каждого UA по служебному VLAN-X.
4. Периодический контроль доступности интерфейсов. При изменении списка доступных интерфейсов отправляется команда на регистрацию UA для нового интерфейса, либо на отмену регистрации если интерфейс выключен или исчез. Необходимо производить попытки повторной регистрации через длительный интервал для UA, у которых регистрация не было подтверждена со стороны SIP-сервера.
5. На служебном интерфейсе медиасервер открывает слушающий порт 5700, по которому с ECSS-10 приходит запрос на определение контрольного канала (control_channel) управления медиа по протоколу mediactrl.

Данные, необходимые для работы медиасервера

1. Адрес для привязки SIP: адрес VLAN-X SIP INTERNAL — служебного VLAN (сетевого интерфейса) для SIP сигнализации. После выбора интерфейса из списка доступных при инсталляции считается привязанный к нему адрес.
2. Логин и пароль для прохождения авторизации и аутентификации на SIP-сервере (ECSS-10). Запрашиваются при инсталляции, по умолчанию msr:mediaserver.
3. Имя сервера MSR. Оно будет использоваться при формировании SIP URI медиасервера, которое будет регистрироваться на SIP-сервере. Запрашиваются при инсталляции, по умолчанию предлагаем имя хоста на котором установим MSR.
4. Период перерегистрации. В инсталляционном пакете можно изменить значение периода по умолчанию (либо вручную изменить конфигурационный файл).
5. Адрес SIP-сервера. Регистрация будет отправлена на каждый список доменных имен, IP-адресов. Если доменное имя будет сохраняться в несколько адресов — регистрация пойдет на каждый.

Алгоритм формирования параметров UA для регистрации на ECSS-10

1. Для каждого сетевого интерфейса формируется свой отдельный SIP UA.
2. Один из сетевых интерфейсов отмечается как служебный (на этапе конфигурирования). Через него передается SIP-трафик. UA для этого интерфейса единственный, у которого связка сигнализации и медиа делается на одном и том же сетевом интерфейсе. UA остальных интерфейсов используют транспорт служебного интерфейса для SIP, а привязка приемника/передатчика медиатрафика осуществляется к анонсируемого SIP UA сетевому интерфейсу.
3. Информация об анонсируемом сетевом интерфейсе передается в REGISTER через поле From. Параметры сетевого интерфейса передаются через следующие поля:
   1. P-Eltex-MSR-Iface-Name;
   2. P-Eltex-MSR-Iface-Addr;
   3. P-Eltex-MSR-Acc-Id;
   4. P-Eltex-MSR-CC-Addr (только в служебном);
   5. P-Eltex-MSR-CC-Port (только в служебном);
   6. P-Eltex-MSR-Name.
4. Cc-status, Cc-id & Cc-address(Control channel status, Control channel id & Control channel address) формируются только для служебного интерфейса;
5. URI UA формируется по следующему формату: {interface-name};{msr-contact-id}@{MSR-name}, где:
   • interface-name — имя анонсируемого интерфейса;
   • msr-contact-id — идентификатор dynamic контакта на MSR;
   • MSR-name - имя медиасервера (имя хоста или указанное при инсталляции имя).
6. IFace (анонсируемый интерфейс) имеет вид: interface-name(MEDIA-IP-Address), где:
   • interface-name — имя анонсируемого интерфейса;
   • MEDIA-IP-Address — IP-адрес анонсируемого интерфейса к которому привязывается медиаресурс.

Функционал ECSS-10

1. Для регистрации медиасерверов выделяется отдельный служебный регистратор, который расположен на ядре системы (Core). Регистратор работает в служебном VLAN-X (отдельный порт, выделенный интерфейс).
2. Сигнальный трафик от медиасерверов обрабатывается SIP-сервером, который встроен с ядром (Core) и обрабатывается в служебном VLAN-X.
3. Функционал регистратора:
   1. получение запросов на регистрацию от служебных абонентов медиасерверов;
   2. аутентификация UA, отправившего запрос на регистрацию (по локальной таблице абонентов);
   3. авторизация UA, отправившего запрос на регистрацию (по локальной таблице ограничений);
   4. установка и поддержка заданных настроек периода истечения регистрации;
   5. информирование SIP-сервера о появлении новых регистраций, об отмене регистрации UA (по инициативе UA), об отказе продления регистрации со стороны UA, об отмене регистрации по инициативе SIP-сервера (по команде системы управления);
   6. прием корректных запросов на регистрацию (корректный RURI и аутентификация). Обслуживание трафика на зарегистрированном ресурсе начинается если он полностью сконфигурирован и не заблокирован административно;
   7. передача нотификации в подсистему установления контрольного канала (control_channel) после прохождения успешной регистрации нового медиасервера (служебного UA — msr-root). В нотификации указывается SIP URI служебного UA медиасервера.
   8. передача нотификации в подсистему установления контрольного канала (control_channel) при потере регистрации служебного UA (msr-root) медиасервера, либо при принудительном отказе в регистрации.
4. Функционал SIP-сервера:
   1. установка SIP-сессий с выбранным аккаунтом;
   2. поддержка установленных SIP-сессий (механизм reINVITE);
   3. нотификация о фактах развала SIP-сессии по инициативе MSR (либо при потере связи с MSR).
5. Функционал управления контрольными каналами:
   1. установка и поддержка контрольных каналов по одному до каждого медиасервера;
   2. сворачивание контрольного канала в случае отказа в регистрации медиасревера;
   3. передача mediactrl-сообщений в нужный контрольный канал, который выбирается по идентификатору канала (равен служебному SIP URI медиасервера).

Настройка медиасервера

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

1. Установка медиасервера

Установка программного медиасервера производится из репозитория ECSS-10, пакет ecss-media-server.

Перед установкой рекомендуется удалить старые версии медиасервера вместе с конфигурацией, если они были установлены ранее:

Например:

sudo apt purge ecss-media-server

Для установки в консоли ОС Linux необходимо выполнить команду:

sudo apt update
sudo apt install ecss-media-server

В ходе установки необходимо будет ответить на ряд вопросов для формирования, основных параметров, конфигурационного XML-файла. Описание параметров приведено на странице Настройка конфигурационного файла MSR.

2. Настройка конфигурационных файлов MSR

Конфигурационный XML-файл после установки медиасервера находится по пути /etc/ecss/ecss-media-server/config.xml.

Параметры в конфигурационном файле сгруппированы в секции (теги XML) таким образом:

config
|--- general
|--- transport
|--- turn-server
|--- media
|--- codec
|--- ivr
|--- accounts
|--- pbyte
|--- conf_dir
|--- rtp

Внутри каждой секции (тега XML) параметры тоже могут группироваться во вложенные теги и указываются как XML-атрибуты (name="value").

Для каждого параметра имеется значение по умолчанию, поэтому формально ни одна секция не является обязательной для указания в конфигурационном файле, но разумеется, это не значит, что отсутствие какой-то секции при конфигурировании MSR не скажется негативно на его работе.
Например, отсутствие секции codec будет означать, что все кодеки отключены и смысл работы медиасервера исчезает, а применение значения по умолчанию transport/bind-addr и вовсе сделает медиасервер неработоспособным.

Значение "по умолчанию" - это значение, используемое при отсутствии параметра в конфигурационном файле и/или предустановленные в deb.
Многие значения уже присутствуют в базовом config.xml, содержащимся внутри deb-пакета ecss-media-server (*deb-config). 
Он помещается по стандартному пути (/etc/ecss/ecss-media-server/config.xml). Если настройка присутствует в базовом файле конфигурации и её значение отличается от значения по умолчанию, оно приводится ниже в описании настроек с пометкой *base-config.
Также при установке / переустановке или запуске dpkg-reconfigure значения параметров могут меняться. Во время выполнения скриптов установки запрашиваются значения нескольких (не всех) параметров на изменение. При этом их текущие значения предварительно считываются из config.xml файла,  либо берутся из deb-шаблона и отображаются в полях ввода скрипта установки как дефолтные. Вне зависимости от того, изменил пользователь настройки в полях ввода или нет, введённые (применённые) значения вносятся снова в config.xml. Если настройка  анализируется/проверяется deb-скриптом, в её описании есть пометка *deb-config.

Основные моменты

1

Медиа сервер, используя данные из секции transport bind-addr направляет регистрацию на ядро, используя секцию accounts.

2

Ядро в реальном времени контролирует доступность медиа сервера с помощью механизма zmq коннекции, для этого настраивается секция pbyte mcc bind-addr.

3

Секция accounts не настраивается в config.xml, это опасно при обновлении, сейчас по умолчанию она вынесена в /etc/ecss/ecss-media-server/conf.d/default.xml

<?xml version="1.0"?>
<config>
  <accounts>
    <dynamic msr_name="msr.ecss1" realm="sip:192.168.1.40:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password">
      <via dynamic-ifaces="no">
          <iface name="bond1.75" ip="192.168.1.27"/>
          <iface name="bond1.20" ip="192.168.1.28"/>
          <iface name="bond1.35" ip="192.168.1.29"/>
          <iface name="bond1.36" ip="192.168.1.30"/>
      </via>
    </dynamic>
    <dynamic msr_name="msr.ecss1" realm="sip:192.168.1.50:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password">
      <via dynamic-ifaces="no">
          <iface name="bond1.75" ip="192.168.1.27"/>
          <iface name="bond1.20" ip="192.168.1.28"/>
          <iface name="bond1.35" ip="192.168.1.29"/>
          <iface name="bond1.36" ip="192.168.1.30"/>
      </via>
    </dynamic>
  </accounts>
</config>

Пример конфигурационного файла:

<?xml version="1.0" encoding="utf-8"?>
<config date="14:39:00 10.03.2023">
  <general log-level="3" log-rotate="yes" max-calls="8192" max-in-group="512" load-sensor="media" load-delta="10" calls-delta="100" spool-dir-size="100M" log-name="msr.log" log-path="/var/log/ecss/media-server" use-srtp="disabled" enable-ice-transport="no" ice-update="no" aggressive-ice="yes" stun-server="" suspicious-mode="no"/>
  <transport bind-addr="192.168.1.40" port="5040" transport="udp+tcp"/>
  <!-- By default configured public TURN-server -->
  <turn-server use-turn="no" host="numb.viagenie.ca" user="webrtc@live.com" password="muazkh"/>
  <media mixer-clock-rate="8000" use-vad="no" cng-level="0" jb-size="60" rtcp-timeout="0" rtp-timeout="350" udp-src-check="no" cn-multiplier="3" port-start="12000" port-range="2048" tias-in-sdp="no" thread-cnt="2" vid-enc-threads="2" vid-dec-threads="2" video-conf-layout="evenly" keyframe-interval="1000" vid-decode-delay="100" silent-codec-switch="yes" silence-threshold="-30" dtmf-flash-disable="no" video-dscp="0" other-dscp="0" dummy-video-src="/usr/share/ecss-media-server/video/dummy_video.yuv" video-enc-width="640" video-enc-height="360" finalsilence="1000" rtcp-stat-dump="yes"/>
  <codec pcma="1" pcmu="2" ilbc="0" gsm="0" g722="3" g729="0" speex="0" l16="0" g7221="0" opus="0" h264="1" h263-1998="2" t38="1" tel-event-pt="0"/>
  <accounts>
    <!-- <dynamic msr_name="msr.name"
            realm="sip:127.0.0.1:5000"
            dtmf_mode="rfc+inband+info"
            auth_name="user"
            auth_password="password" /> -->
  </accounts>
  <pbyte>
    <mcc bind-addr="192.168.1.40" port="5700"/>
  </pbyte>
  <conf_dir path="/etc/ecss/ecss-media-server/conf.d"/>
  <rtp>
    <auto addr-v4=""/>
  </rtp>
</config>

где:

• general — общие настройки медиасервера:

  general

  <general
  log-level="3" log-rotate="yes"
  max-calls="8192" max-in-group="512" max-vid-calls="8192"
  load-sensor="media" load-delta="10" calls-delta="100"
  spool-dir-size="100M" log-name="msr.log" log-path="/var/log/ecss/media-server"
  use-srtp="disabled" suspicious-mode="no"
  enable-ice-transport="no" ice-update="no" aggressive-ice="yes" stun-server=""/>

  • log-level — уровень логов. Чем больше значение, тем больше информации в логах (диапазон значений: [0; 6], для тестов/отладки подходит уровень логирования 5, по умолчанию: "3" *deb-config);
  • log-rotate — ротация логов (значения "yes"/"no", по умолчанию: "no") При значении "no" пишется один лог-файл (например, msr.log - согласно log-name). При значении "yes" лог делится на фрагменты - файлы размером не более 50 МБ, их имена имеют вид 2024_10_24_17_30_48_msr.log и генерируются по дате/времени создания файла (с добавкой log-name);
  • log-path — путь до директории с логами (по умолчанию: "/var/log/ecss/media-server");
  • log-name — имя файла логов (по умолчанию: "msr.log");
  • syslog — логирование непосредственно в /var/log/syslog, вместо отдельного файла/файлов по пути log-path (значения "yes"/"no" по умолчанию: "no");
  • spool-dir-size — размер каталога /var/spool/ecss/ecss-media-server, предназначенного для хранения временных файлов факсов. При превышении указанного значения старые файлы удаляются (по умолчанию — 100M). Подробнее ниже, в разделе "Тонкая настройка системы";
  • max-calls — максимальное количество одновременно обслуживаемых медиасервером аудио вызовов (по умолчанию: "8192" *base-config);
  • max-vid-calls — максимальное число одновременно обслуживаемых видео-вызовов по умолчанию равно значению max-calls (по умолчанию: "8192" *base-config);

  • max-in-group — максимальное количество абонентов в группе в рамках конференции (по умолчанию: "512" *base-config). Если услуга "Конференц-связь" используется с большим количеством участников, то необходимо увеличить значение данного параметра. Максимальное значение 4000; Поскольку участниками объекта конференция (логически) могут быть не только вызываемые абоненты, но и другие конференции (проключение между конференциями), а также объекты диалогов (для воспроизведения сигналов/аудиозаписей и для записи разговоров в аудио-файлы), нужно учитывать, что при указании, например, max-in-group="100" и попытке создать конференцию из 100 участников, некоторые участники (несколько последних подключаемых) не смогут в неё попасть. Лучше указывать значение заведомо больше необходимого в этом параметре;

  • load-sensor — включение механизма информирования ядра о загрузке msr (список значений: "media"/"none" по умолчанию — media *base-config). Информация о загрузке передаётся не чаще одного раза в секунду, если использование CPU MSR-ом и/или число вызовов изменилось в сравнении с предыдущими переданными значениями (порог чувствительности задаётся параметрами load-delta и calls-delta, описаны ниже) Информация о загрузке MSR передаётся на каждое ядро SSW, через сообщение SIP PUBLISH с Event eltex-load-sensor, в Body передаётся строка вида "load: 30 calls: 380" (text\plain);
  • load-delta — определяет относительное изменение - дельта (сравнение текущей загрузки с предыдущей) загрузки msr (от 1 до 100), при которой формируется нотификации о текущей загрузке msr (не чаще 1 раза в секунду). Коэффициент загрузки отправляется в каждое ядро посредством SIP PUBLISH с Event eltex-load-sensor, в Body находится текущая загрузка msr (по умолчанию — 10);
  • calls-delta — минимальная дельта (разница) изменения количества вызовов для отправки уведомления ядру (диапазон значений: [0; 1000] по умолчанию: "100");
  • use-srtp — использование SRTP (значения: "disabled" — SRTP не используется(только RTP), "optional" — будет возможность звонить как с RTP, так и с SRTP (RTP+SRTP), "mandatory" будет использоваться только SRTP (RTP-звонки приниматься не будут) (по умолчанию: "disabled");
  • secure-signaling — "no" - SRTP не требует secure signaling (защищенной сигнализации). "yes" - SRTP требует безопасный транспорт, как TLS. "sips" - SRTP требует SIP Secure (SIPS).(по умолчанию: "no");
  • suspicious-mode — завершение процесса MSR при потере соединения по Control channel/контрольной коннекции, (значения "yes"/"no", по умолчанию "no");

  • ipv6-support="yes/no" — включить поддержку IPv6. (значения "yes"/"no", по умолчанию "no");

  • enable-ice-transport="yes/no" — позволяет использовать SRTP/DTLS при WebRTC-вызове, даже если задано use-srtp="disabled"; (значения "yes"/"no" по умолчанию: "no");
  • ice-update="yes/no" — включение SIP UPDATE для конечного согласования ICE-кандидатов (значения "yes"/"no" *base-config: "yes");
  • aggressive-ice="yes/no" — включение агрессивной номинации ICE - это может применяться только при отмене Trickle-ICE; (значения "yes"/"no" *base-config: "yes");
  • stun-server — адрес или имя STUN-сервера. (по умолчанию: "" (пуст)).

• transport — настройки транспорта:

  transport

  <transport bind-addr="192.168.1.40" port="5040" transport="udp+tcp"/>

  • bind-addr — IP-адрес, который будет использовать медиасервер для SIP-сигнализации (по умолчанию: "127.0.0.1" *deb-config).
    
    

    Данный параметр необходимо настроить в соответствии с сетевыми настройками хоста. Нужно заменить внутренний 127.0.0.1 на внешний;
  • port — номер порта для SIP (по умолчанию: "5040"). Если на хосте, где установлен медиасервер, порт 5040 уже занят, то значение данного параметра необходимо изменить;
  • transport — тип транспорта (по умолчанию: "udp+tcp"), принимает значения: "udp", "tcp", "udp+tcp". Данный параметр не требует изменений.

• turn-server — настройки TURN-сервера;

  turn-server

  <turn-server use-turn="no" host="numb.viagenie.ca" user="webrtc@live.com" password="muazkh"/>

  • use-turn="yes/no" — использовать или нет TURN (по умолчанию: "no");
  • host — имя или адрес сервера (по умолчанию "numb.viagenie.ca" *base-config);
  • user — имя пользователя, (по умолчанию "webrtc@live.com" *base-config);
  • password — пароль пользователя (по умолчанию "muazkh" *base-config).

• media — параметры медиа:

  media

  <media mixer-clock-rate="8000" use-vad="no" cng-level="0" 
  jb-size="60" rtcp-timeout="0" rtp-timeout="350" udp-src-check="no" cn-multiplier="3" 
  port-start="12000" port-range="2048" 
  tias-in-sdp="no" thread-cnt="2" vid-enc-threads="2" vid-dec-threads="2" video-conf-layout="evenly" keyframe-interval="1000" vid-decode-delay="100" 
  silence-threshold="-30" dtmf-flash-disable="no" video-dscp="0" other-dscp="0" 
  dummy-video-src="/usr/share/ecss-media-server/video/dummy_video.yuv" video-enc-width="640" video-enc-height="360" finalsilence="1000" rtcp-stat-dump="yes"/>

  • session-name — название сессии (строка 's=ECSS-10') для создаваемых SDP (по умолчанию: "ECSS-10");
  • imageattr-x / imageattr-y / imageattr-q — разрешение видео по горизонтали параметры для формирования атрибута imageattr для части 'm=video' в SDP (для поддержки некоторого оборудования, например, Cisco) (по умолчанию, соответственно "640", "480", "0.5"), что в SDP формирует строку: a = imageattr: * recv [x=640,y=480,q=0.50];

  • mixer-clock-rate — частота, используемая внутренним микшером медиасервера (по умолчанию: "8000" *deb-config). Интервал возможных значений: [0; 48000] при значении <= 0 выставляется 8000. при значении > 48000 выставляется 48000 и выдаётся предупреждение в лог;

    

    • При установке ECSS-10 версии 3.14 данный параметр по умолчанию имеет значение 8000. Это сделано для поддержки HD-кодеков, а также уверенного распознавания речи в таких сервисах как IVR, транскрибирование, ASR.
    • Выставление mixer-clock-rate = 48000 приводит к увеличению нагрузки на CPU, увеличение сетевого трафика и объема записанных файлов разговоров.
    • При штатном обновлении этот параметр сам собой не изменится. Данный параметр настраивается в соответствии с аппаратными возможностями сети (например, для поддержки работы G.722 в режиме HD параметр устанавливается в соответствии с частотой дискретизации данного кодека "16000"). Диапазон значений — 8000-48000. Если будет задано значение > 48000, то будет установлено в 48000. В syslog будет предупреждение об этом).
  • bind-addr — IP-адрес для RTP-портов, создаваемых медиасервером для работы медиа-портов (по умолчанию: "" (пуст)), и в этом случае используется IP-адрес из transport/bind-addr;
  • use-vad — включить Voice Activity Detection (определение голоса) (значения "yes"/"no" по умолчанию: "no"). Данный параметр не требует изменений;
  • udp-src-check — при включенной опции ("yes") ECSS-10 будет посылать медиа-трафик на тот IP:Port с которого приходит вызов по транспорту. Используется для вызовов, приходящих из за NAT. При значении "yes" транспорт UDP для "RTP-потока" постоянно проверяет адрес источника входящих пакетов, чтобы убедиться, что он отличается от настроенного удаленного адреса, и переключает удаленный адрес на адрес источника пакета, если они отличаются, после получения нескольких пакетов. При значении "no" эта проверка отключена. (по умолчанию: "no");

  • cng-level – 0 — (значение по умолчанию -64 dBm). По умолчанию указывается "0" в целях сохранения обратной совместимости. Диапазон применимых значений 3–127 (где значение 3 означает максимальный шум, а 127 — полную тишину).

    

    cng-level в файле конфигурации:
    1) Если не указан параметр MSR cng-level, то генерация CN отключена. Если указано cng-level="0"(значение по умолчанию) либо указано некорректное значение →  вне интервала [3; 127], то применяется дефолтное 64, означающее -64 dBm. Иначе используется значение уровня шума из параметра MSR cng-level.
    
    Обратите внимание, что в RTP пакетах с CN передаётся значение уровня шума Lov(dBov) без знака минус, причём в диапазоне [3; 127] (G.100.1, максимальный уровень всегда -3.01 dBov). Поскольку есть инверсия знака, то значение 3 означает максимальный шум, а 127 — полную тишину.
    Уровень CN (по умолчанию) соответствует уровню шума в Λ = -64 dBm., такой шум является приемлемым для comfort noise. Вот расчёт:
    Если за основу брать порог чувствительности (обычный) человеческого уха (на частоте 1 кГц) как 10^-12 Вт = -90 dBm (L1), а допустимый шум принять 26 децибел L(dB) = 26 dB, то т.к. L(dB) = L2 - L1, получаем оценку искомого уровня Λ(dBm):
    L2 = 26 dBm + (-90 dB) = -64 dBm.
    
    2) Принятое значение уровня Lov(dBov) применяется как значение CN (с обратным знаком), причём:
    Lov(dBov) = Λ(dBm) - 5 dB Λ(dBm) для всех кодеков, кроме PCMU, PCMA и G.722 — для них, в значении CN, применяются иные понижающие коэффициенты:
    A-law: Lov(dBov) = ΛA (dBm0) - 6.15 dB
    μ-law: Lov(dBov) = Λμ (dBm0) - 6.18 dB
    G.722: Lov(dBov) = ΛG.722 (dBm0) - 12.01 dB
    прочие кодеки: Lov (dBov) = Λ (dBm) - 5 dB
    Пример:
    указано cng-level="70", тогда для различных кодеков расчёт передаваемого CN таков:
    A-law: Lov(dBov) = -70 dBm - 6.15 dBm= -76.15 dBm, CN = 76
    μ-law: Lov(dBov) = -70 dBm - 6.18 dBm= -76.18 dBm, CN = 76
    G.722: Lov(dBov) = -70 dBm - 12.01 dBm= -82.01 dBm, CN = 82
    для прочих кодеков = -70 dBm - 5 dBm= -75dBm, CN = 75

  • jb-size — размер jitter-буфера, в миллисекундах, то есть максимальная задержка в мс, которая будет вноситься для поддержания непрерывного потока media. (по умолчанию = 60);
  • echo-cancel-algo — алгоритм, используемый для эхокомпенсации. Реализованы алгоритмы:
    • simple — простой алгоритм эхозаграждения, наименее предпочтительный;
    • speex — алгоритм, реализованный в кодеке speex, немного искажает звук; 
    • webrtc — алгоритм, реализованный в webrtc, используется по умолчанию;
    • webrtc3 — алгоритм WebRTC AEC3. При использовании кодека OPUS эхоподавитель работает с 32 kb/s и 48 kb/s аудио.
  • echo-cancel-aggr — параметр определяет агрессивность эхокомпенсации. (low — низкая; mid — средняя; (по умолчанию=high — максимальная ));
  • echo-cancel-tail — длина буфера эхокомпенсатора в миллисекундах, если задано "0", то эхокомпенсатор отключён. (по умолчанию: "200");
  • rtcp-timeout — если в течение этого периода времени не приходит RTCP медиасерверу, то можно считать, что клиент неактивен (по умолчанию: "0" — не используется). При использовании функции контроля, контроль включается только после приема от встречной стороны первого RTCP-пакета;
  • rtcp-stat-dump — вывод RTCP-статистики в логи . Работает только при уровне логов выше 2, значения: "yes"/"no" (по умолчанию: "yes" — используется);
  • rtp-timeout — если в течение этого периода времени (в секундах) медиасерверу от клиента не приходит RTP, то считать, что клиент не активен. Значение "0" эту функцию отключает.(по умолчанию: "350");
  • cn-multiplier — множитель к rtp-timeout, если последний полученный RTP-пакет был с comfort noise (по умолчанию: "3");
  • port-start — начало диапазона портов, которые будут использоваться для RTP-потоков (по умолчанию: "12000");
  • port-range — размер диапазона портов для RTP-потоков по умолчанию: general/max-calls * 4, здесь 4 - это количество портов на абонента с аудио и видео: (RTP + RTCP) * 2.(по умолчанию: "2048");
  • tias-in-sdp — включение/отключение передачи атрибута b=TIAS/(не b=AS) в offer SDP (в части audio) (по умолчанию: "no");
  • thread-cnt — количество рабочих потоков для обработки медиаданных (аудио, без видео), (поdtmf-to-total-energy, по умолчанию: "2"). Параметр по-прежнему определяет количество потоков старого конференц-бриджа, который больше не занимается микшированием видео.;
  • silent-codec-switch – включение опции для управления режимом "тихой" смены кодека, если данная опция включена, то MSR меняет кодек при получении RTP пакета с номером payload type'а, который он не ожидал, если кодек имеется в списке согласованных. Смена кодеков работает только для аудио, и только при включённой опции silent-codec-switch. Значения: "yes"/"no" (по умолчанию:  "yes" — включена);
  • silence-threshold — пороговый уровень тишины для Voicemail в дБ (по умолчанию: "-30" дБ *base-config);
  • dummy-video-src — путь к файлу видеозаставки (формат YUV420), которая отображается при отсутствии видеопотока (по умолчанию /usr/share/ecss-media-server/video/dummy_video.yuv *deb-config);
  • video-enc-width и video-enc-height — параметры задают исходящее разрешение видеопотока. Все кадры, поступающие на энкодер, с шириной или высотой больше данных будут конвертированы в данный размер. По умолчанию устанавливаются в 640×360 *base-config.
  • video-dscp — значение задаёт маркировку трафика с целью приоритизации DCSP (Differentiated Service Code Point, DSCP), для видео (по умолчанию — 0, т.е. без DSCP);
  • video-conf-layout — режим заполнения сетки видео-участников, может принимать 2 значения:
    • evenly — cтандартный режим, при котором все источники видео (участники) будут помещены в сетку с одинаковым разрешением. При этом могут остаться "пустые" места без видео (по умолчанию).
    • adaptive — адаптивный режим для использования всей сетки. Данный режим может выделять нескольких участников, увеличивая их разрешение.
  • other-dscp — значение задаёт маркировку трафика с целью приоритизации DCSP (Differentiated Service Code Point, DSCP), для остальных типов медиа (по умолчанию — 0, т.е. без DSCP);
  • dtmf-hits-to-begin — (один hit равен 12,75 с) — количество детекций подряд одного и того же сигнала, который распознается в DTMF (по умолчанию — 3; возможные значения: 1..10);
  • dtmf-misses-to-end — (один miss равен 12,75 с) — количество детекций подряд НЕ DTMF-сигнала следом за указанным количеством hit-ов, которые распознали DTMF-сигнал (по умолчанию — 3; возможные значения: 1..10);
  • dtmf-flash-disable — отключение отправки DTMF flash  значения: "yes"/"no" (по умолчанию: "no");
  • dtmf-relative-peak — настройки управления чувствительностью DTMF-детектора: излишняя чувствительность детектора приводит иногда к ложным срабатываниям на голос. С этими настройками сравнивается "энергия" максимально подходящих фрагментов фреймов. Диапазон значений: [5.0; 30.0] (по умолчанию: "9.0");
  • dtmf-to-total-energy — настройки управления чувствительностью DTMF-детектора: излишняя чувствительность детектора приводит иногда к ложным срабатываниям на голос. С этими настройками сравнивается "энергия" максимально подходящих фрагментов фреймов. Диапазон значений:  [32.0; 70.0]  (по умолчанию: "38.0");
  • keyframe-interval — интервал времени между отправкой ключевых видеокадров в миллисекундах (по умолчанию "1000" *base-config);
  • vid-decode-delay — минимальная задержка видеопотока в миллисекундах перед началом его декодирования (по умолчанию: "100");

  • vid-enc-threads — количество потоков кодера (encoder) (по умолчанию: "2");

  • vid-dec-threads — количество потоков декодера (по умолчанию: "2" *base-config);

  • dtmf-tg-fpc-loop — Параметр для настройки тоногенератора - количество циклов расчёта для генерации тона; чем больше циклов, тем качественнее тон диапазон значений: [1; 28] (по умолчанию: "10");
  • dtmf-tg-fit — Параметр для настройки тоногенератора - длительность постепенного появления тона, в миллисекундах диапазон значений: [1; 50] (по умолчанию: "1");
  • dtmf-tg-fot — Параметр для настройки тоногенератора - длительность затухания тона, в миллисекундах диапазон значений: [1; 50] (по умолчанию: "2");
  • dtmf-tg-volume — Параметр для настройки тоногенератора - амплитуда генерируемого тона диапазон значений: [1; 32767] (по умолчанию: "12288");
  • finalsilence — как только на протяжении finalsilence секунд будет продетектирована тишина — завершается запись разговора (по умолчанию: "1000");
• codec — приоритеты кодеков (1 — максимальный, 255 — минимальный, 0 — кодек отключен).
  
  codec

  <codec pcma="1" pcmu="2" ilbc="0" gsm="0" g722="3" g729="0" speex="0" l16="0" g7221="0" opus="0" h264="1" h263-1998="2" t38="1" tel-event-pt="0"/>  

  По умолчанию *deb-config: ненулевые в deb-шаблоне следующие: pcma="1", pcmu="2", g722="3", h264="1" и h263-1998="2".
  Приоритет кодека определяет порядок расположения кодеков в SDP: кодеки с наибольшим приоритетом располагаются в SDP в начале, затем - в порядке уменьшения приоритета. В случае, если приоритет двух или более кодеков, поддерживаемых в SDP обоими плечами вызова, одинаков, то MSR для RTP-сессии выбирает любой из них.
  
  Поддерживаемые кодеки: 
  
  • pcma
  • pcmu
  • ilbc
  • gsm 
  • g722
  • g722.1
  • g729
  • speex
  • l16
  • opus
  • h264
  • h263-1998
  • t38
  • tel-event-pt
    
    
• accounts — параметры регистрации MSR на ядре SSW. Секция может содержать один или несколько (формально до 1000) тегов dynamic с параметрами динамического аккаунта - атрибутами:

Есть два основных варианта сообщения SIP REGISTER ядру SSW со стороны MSR:
1) master-регистрация - с IP, указанного в параметре pbyte/bind-addr
2) обычные регистрации - с других сетевых интерфейсов/IP

Тег dynamic может содержать вложенный тег via с вложенным списком тегов iface (максимум - 20). Каждый тег iface имеет обязательные атрибуты name (имя интерфейса) и ip (IP-адрес интерфейса), если значение хотя бы одного из них пустая строка, то тег пропускается (игнорируется).

Также тег via может содержать необязательный атрибут dynamic-ifaces, означающий использование динамических интерфейсов при значении "yes" (оно же значение по умолчанию). Использование тега via позволяет подменить в заголовке Via сообщения SIP REGISTER (от MSR - ядру) указанный IP-адрес. Благодаря этому можно избежать многих ошибок/конфликтов регистраций, в т.ч. при работе через VLAN.

Алгоритм обработки информации для тегов со вложенностью accounts/dynamic/via и атрибута dynamic-ifaces приведён в блок-схеме ниже:

• •  dynamic — отдельный аккаунт с параметрами:
    • msr_name — имя медиасервера MSR, прописывается в заголовок P-Eltex-MSR-Name сообщения SIP REGISTER ,  - если параметр не указан (""), данный тег dynamic не будет обработан (по умолчанию *deb-config: "msr.name");
    • realm — сервер регистрации в формате sip:domain, либо sip:domain:port. Указывается адрес SIP-сервера для регистрации медиасервера  - если параметр не указан (""), данный тег dynamic не будет обработан (по умолчанию: *deb-config: "sip:127.0.0.1:5000");
    • dtmf_mode — режим детектирования DTMF ("rfc", "inband", "info"). Данный параметр необходимо настроить в соответствии с настройками отправки DTMF на абонентском устройстве. (по умолчанию: *deb-config: "rfc+inband+info");
    • auth_name — имя пользователя, используемое для авторизации (по умолчанию: *deb-config: "user");

    • auth_password — пароль для авторизации (по умолчанию: *deb-config: "password");

    • via — В случае использования для сигнальной сети нескольких vlan-ов , необходимо скорректировать конфигурационный файл /etc/ecss/ecss-media-server/config.xml описав параметр "via":

      

      via — задается список интерфейсов, которые могут быть отправлены в сообщении "SIP REGISTER" поле "Via":

      • dynamic-ifaces — значение = "yes" или "no";
        • если dynamic-ifaces="no":
          - при мастер-регистрации всё как раньше
          - в ином случае регистрация проходит ТОЛЬКО если интерфейс перечислен в списке via в конфиг файле
        • если dynamic-ifaces="yes" или атрибут не указан, то регистрация будет идти со всех интерфейсов.
      • iface name — имя интерфейса;
      • ip — ip адрес интерфейса.
        - если указанный в конфиге в разделе via ip-адрес не существует, он не обрабатывается (пропускается)
        - если указан верный ip, то он прикрепляется для регистрации в заголовок Via
        - при отсутствии интерфейса в конфиге в via при мастер-регистрации указывается bind-address из конфига, при при не-мастер регистрации поведение прежнее.

      • пример для одиночного хоста

        <?xml version="1.0"?>
        <config>
          <accounts>
            <dynamic msr_name="msr.ecss1" realm="sip:192.168.1.40:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password">
              <via dynamic-ifaces="no">
                  <iface name="bond1.75" ip="192.168.1.27"/>
                  <iface name="bond1.20" ip="192.168.1.28"/>
                  <iface name="bond1.35" ip="192.168.1.29"/>
                  <iface name="bond1.36" ip="192.168.1.30"/>
              </via>
            </dynamic>
          </accounts>
        </config>

        CODE

      • пример для кластерной конфигурации

        <?xml version="1.0"?>
        <config>
          <accounts>
            <dynamic msr_name="msr.ecss1" realm="sip:192.168.1.40:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password">
              <via dynamic-ifaces="no">
                  <iface name="bond1.75" ip="192.168.1.27"/>
                  <iface name="bond1.20" ip="192.168.1.28"/>
                  <iface name="bond1.35" ip="192.168.1.29"/>
                  <iface name="bond1.36" ip="192.168.1.30"/>
              </via>
            </dynamic>
            <dynamic msr_name="msr.ecss1" realm="sip:192.168.1.50:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password">
              <via dynamic-ifaces="no">
                  <iface name="bond1.75" ip="192.168.1.27"/>
                  <iface name="bond1.20" ip="192.168.1.28"/>
                  <iface name="bond1.35" ip="192.168.1.29"/>
                  <iface name="bond1.36" ip="192.168.1.30"/>
              </via>
            </dynamic>
          </accounts>
        </config>

        CODE
• rtp — режим подмены IP в sdp. Может происходить в двух режимах - автоматическом (тег auto в секции rtp), когда задаётся общий IP для всех интерфейсов и/или  ручном  при указании интерфейса(ов) по имени name (один или несколько тегов manual в секции rtp).
  
  rtp

  <rtp>
    <auto addr_v4="192.168.1.2" addr_v6="::1" />
    <manual name="eth0" addr_v4="192.168.1.3" addr_v6="::1" />
    <manual name="vlan3495" addr_v4="192.168.80.100" addr_v6="::1" />
    <!-- .... -->
</rtp>

  В теге auto и в теге manual из атрибутов addr-v4 и addr-v6 (содержат публичные IP на замену) должен быть задан хотя бы один. В каждом теге manual атрибут name обязателен.

  В одном конфигурационном файле могут быть применены оба режима - и auto, и manual, но приоритет имеют строки manual. И если ни одна строка manual не сработала (интерфейс отсутствует или адрес не резолвится), то тогда обрабатывается тег auto.

  • auto  — автоматический режим. Определяет общий IP для всех sdp, например : <auto addr-v4="192.168.1.2" addr-v6="::1"/>

  • manual — ручной режим. Задаются пары интерфейс-IP, например: <manual name="eth0" addr-v4="192.168.1.3" addr-v6="::1">
• pbyte — настройки канала контрольной коннекции pbyte. Тут находятся настройки соединения (канала) для управления медией - media control channel (MCC), т.н. "контрольной коннекцией". В медиасервере и ядре SSW передача сообщений по каналу MCC реализована на основе транспортного протокола PBYTE.
  По типу заголовка в протоколе PBYTE есть сообщения CONREQ, CONRESP, CONUPD, CONUPDACK и TRANSFER. Сообщения типа TRANSFER также имеют payload с MCC-сообщением внутри.
  Соединение по контрольной коннекции устанавливается так:
  1) ядро отсылает MSR-у сообщение CONREQ (запрос), MSR отвечает CONRESP, далее идёт обмен сообщениями TRANSFER
  2) ядро отсылает MSR-у сообщение TRANSFER с MCC-сообщением SYNC в payload, MSR тоже отвечает TRANSFER/SYNC, после этого соединение установлено
  Далее идёт обмен TRANSFER-сообщениями с MCC-сообщениями CONTROL в payload. Сообщения CONTROL обычно сами содержат payload с содержимым в формате XML, а именно ядро отсылает команды, а MSR шлёт ядру на каждую из команд response и отправляет event'ы.
  Если обмен сообщениями TRANSFER останавливается, то в течение периода времени, заданного параметром update-timeout (в секундах, по умолчанию "10"), ядро должно выслать MSR-у PBYTE-сообщение CONUPD (интервал t1 на схеме - от последнего сообщения TRANSFER/CONTROL от MSR ядру до отправки ядром CONUPD). В свою очередь, получив CONUPD, MSR в течение периода времени, заданного параметром ack-timeout (в секундах, по умолчанию "1", интервал t2 на схеме) должен подтвердить ответом CONUPDACK, что соединение по  MCC не потеряно.
  Схема (обобщенная) обмена сообщениями по протоколу PBYTE:
  

  ядро SSW                   MSR
     |                        |
     |--------CONREQ--------->|
     |                        |
     |<-------CONRESP---------|
     |                        |
     |----TRANSFER:SYNC------>|
     |                        |
     |<---TRANSFER:SYNC-------|
     |                        |
     |---TRANSFER:CONTROL---->|
     |    XML-body: command   |
     |                        |
     |<--TRANSFER:CONTROL-----|
     |    XML-body: event or  |
     |              response  |
     |                        |
     ~          ....          ~
     |                        |
     < stop exchange by PBYTE >
     |                        |
     |                    t1  |
     |                        |
     |--------CONUPD--------->|
     |                    t2  |
     |<------CONUPDACK--------|
     |                        |

  pbyte

    <pbyte>
      <mcc bind-addr="192.168.1.40" port="5700"/>
    </pbyte>

  
  
  • mcc — настройка управляющего соединения media control channel;
  • bind-addr — IP-адрес, на котором будет ожидаться подключение;
  • port — порт для входящих подключений, (по умолчанию: 5700).
    
    
• conf_dir path — Имеет единственный параметр path со значением по умолчанию *deb-config: "/etc/ecss/ecss-media-server/conf.d"

  Параметр содержит путь до папки с дополнительными файлами конфигурации MSR. Настройки из этих файлов будут переопределять настройки из основного файла конфигурации (/etc/ecss/ecss-media-server/config.xml).

  Содержащиеся по пути path файлы конфигурации считываются в алфавитном порядке, после считывания основного config.xml.

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

• Не используйте плавающие (keepalive) адреса для медиасервера.
• Не используйте 0.0.0.0 в качестве listen-ip.
• Если вы настроили свой MSR через дефолтный config.xml, то при последующем обновлении или настройке с помощью dpkg-reconfigure он будет полностью перезатерт и сброшен в дефолт. Поэтому свой MSR лучше настраивать в отдельном файле, например в /etc/ecss/ecss-media-server/conf.d/01-ecss-conf.xml.

Переопределять настройки конфигурационных файлов можно в каталогах:

1. /etc/ecss/ecss-media-server/conf.d для файла config.xml;
2. /etc/ecss/ecss-media-server/conf-without-video.d — для файла config-without-video.xml;
3. В общем случае — /etc/ecss/ecss-media-server/conf-<имя_запускаемого_экземпляра_msr>.d — для файла config-<имя_запускаемого_экземпляра_msr>..xml.

Подробнее о запуске нескольких экземпляров см. ниже, в разделе "Запуск медиасервера".

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

<!-- 01-ecss-conf.xml -->
<?xml version="1.0" encoding="utf-8"?>
<config>
  <general log-level="4" />
  <accounts>
    <dynamic msr_name="some name" realm="sip:x.x.x.x:zzzz" 
        dtmf_mode="rfc+inband+info" auth_name="user1" auth_password="password123"/>
  </accounts>
</config>

<!-- 02-ecss-conf.xml -->
<?xml version="1.0" encoding="utf-8"?>
<config>
  <rtp>
    <auto name="1.1.1.1"/>
   </rtp>
</config>

В результате должен переопределиться уровень логирования и добавиться аккаунт, а также включена опция подмены IP в sdp.

Логика выбора медиасервером адреса под RTP

На медиасервером выбор адреса для работы с потоками RTP влияют несколько параметров:

• transport/bind-addr
• accounts/dynamic/via
• media/bind-addr
• секция rtp

Нужно разграничить потоки RTP, используемые медиа-портами медиасервера (стрим-порты, URL-плеер-порты и т.д.) и потоки RTP для вызовов (IP:port этих потоков указывается MSR-ом в SDP).

IP-адрес RTP-потоков для медиа-портов берётся из параметра media/bind-addr, а если он не указан - из параметра transport/bind-addr.

Выбор медиасервером IP-адреса для RTP в SDP при вызове от ядра происходит так:

1) Через объект net_config MSR получает список сетевых интерфейсов системы и сопоставленных с ними подсетей, с информацией, активны или нет эти сетевые интерфейсы.

2) Если в полученном списке есть интерфейс для IP, указанного в transport/bind-addr, то он используется в мастер-регистрации. Если такой интерфейс не найден, выдаётся сообщение об ошибке в лог и MSR завершает работу.

4) Запускаются мастер-регистрации для каждого из динамических аккаунтов - их параметры перечислены в тегах dynamic внутри секции accounts.  В свойствах каждого аккаунта для RTP указывается IP-адрес, указанный в transport/bind-addr.

5) Для прочих сетевых интерфейсов из списка, хранимого net_config, запускается обычная (не-мастер) регистрация (если она не отменена при обработке тега via), и для RTP используется адрес сопоставленной с интерфейсом подсети.

6) Секция rtp с указанием интерфейсов и подмены адресов для RTP прямо в SDP - это уже устаревший механизм, применявшийся раньше, когда использовались статические аккаунты. Если она применяется, то MSR подменит в SDP IP-адрес для RTP на указанные в этой секции (вместо адреса подсети, сопоставленной с указанными сетевыми интерфейсами) - эта подмена происходит после работы логики регистраций и для указанных в секции rtp адресов RTP отменяет её.

default.xml

Конфигурационный XML-файл после установки медиасервера находится по пути /etc/ecss/ecss-media-server/conf.d/default.xml.

Параметры в конфигурационном файле сгруппированы в секции (теги XML) таким образом:

config
|--- accounts
    |--- dynamic
        |--- via
             |--- iface

После инсталляции пакетов в фале будет указан  ip-add 127.0.0.1 , и только для одного хоста.

<?xml version="1.0"?>
<config>
      <accounts>
            <dynamic msr_name="msr.ecss1" realm="sip:127.0.0.1:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password"/>
      </accounts>
</config>

Требуется указать в конфигурации для обоих хостов, реальные IP-add.

Необходимо привести содержимое файла к виду указанному снизу (в примере ecss1 имеет IP-add 192.168.1.40/ ecss2 - 192.168.1.50, параметр "via / iface name" при необходимости):

Внутри каждой секции (тега XML) параметры тоже могут группироваться во вложенные теги и указываются как XML-атрибуты (name="value").

Пример конфигурационного файла:

<?xml version="1.0"?>
<config>
  <accounts>
    <dynamic msr_name="msr.ecss1" realm="sip:192.168.1.40:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password">
      <via dynamic-ifaces="no">
          <iface name="bond1.75" ip="192.168.1.27"/>
          <iface name="bond1.20" ip="192.168.1.28"/>
          <iface name="bond1.35" ip="192.168.1.29"/>
          <iface name="bond1.36" ip="192.168.1.30"/>
      </via>
    </dynamic>
    <dynamic msr_name="msr.ecss1" realm="sip:192.168.1.50:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password">
      <via dynamic-ifaces="no">
          <iface name="bond1.75" ip="192.168.1.27"/>
          <iface name="bond1.20" ip="192.168.1.28"/>
          <iface name="bond1.35" ip="192.168.1.29"/>
          <iface name="bond1.36" ip="192.168.1.30"/>
      </via>
    </dynamic>
  </accounts>
</config>

где:

• accounts — параметры регистрации MSR на ядре SSW. Секция может содержать один или несколько (формально до 1000) тегов dynamic с параметрами динамического аккаунта - атрибутами:

  

  Есть два основных варианта сообщения SIP REGISTER ядру SSW со стороны MSR:
  1) master-регистрация - с IP, указанного в параметре pbyte/bind-addr
  2) обычные регистрации - с других сетевых интерфейсов/IP

  Тег dynamic может содержать вложенный тег via с вложенным списком тегов iface (максимум - 20). Каждый тег iface имеет обязательные атрибуты name (имя интерфейса) и ip (IP-адрес интерфейса), если значение хотя бы одного из них пустая строка, то тег пропускается (игнорируется).

  Также тег via может содержать необязательный атрибут dynamic-ifaces, означающий использование динамических интерфейсов при значении "yes" (оно же значение по умолчанию). Использование тега via позволяет подменить в заголовке Via сообщения SIP REGISTER (от MSR - ядру) указанный IP-адрес. Благодаря этому можно избежать многих ошибок/конфликтов регистраций, в т.ч. при работе через VLAN.

  Алгоритм обработки информации для тегов со вложенностью accounts/dynamic/via и атрибута dynamic-ifaces приведён в блок-схеме ниже:

  

  
  

• dynamic — отдельный аккаунт с параметрами:
  • msr_name — имя медиасервера MSR, прописывается в заголовок P-Eltex-MSR-Name сообщения SIP REGISTER ,  - если параметр не указан (""), данный тег dynamic не будет обработан (по умолчанию *deb-config: "msr.name");
  • realm — сервер регистрации в формате sip:domain, либо sip:domain:port. Указывается адрес SIP-сервера для регистрации медиасервера  - если параметр не указан (""), данный тег dynamic не будет обработан (по умолчанию: *deb-config: "sip:127.0.0.1:5000");
  • dtmf_mode — режим детектирования DTMF ("rfc", "inband", "info"). Данный параметр необходимо настроить в соответствии с настройками отправки DTMF на абонентском устройстве. (по умолчанию: *deb-config: "rfc+inband+info");
  • auth_name — имя пользователя, используемое для авторизации (по умолчанию: *deb-config: "user");

  • auth_password — пароль для авторизации (по умолчанию: *deb-config: "password");

  • via — В случае использования для сигнальной сети нескольких vlan-ов , необходимо скорректировать конфигурационный файл /etc/ecss/ecss-media-server/conf.d/default.xml описав параметр "via":

• via — задается список интерфейсов, которые могут быть отправлены в сообщении "SIP REGISTER" поле "Via":
  • dynamic-ifaces — значение = "yes" или "no";
    • если dynamic-ifaces="no":
      - при мастер-регистрации всё как раньше
      - в ином случае регистрация проходит ТОЛЬКО если интерфейс перечислен в списке via в конфиг файле
    • если dynamic-ifaces="yes" или атрибут не указан, то регистрация будет идти со всех интерфейсов.
• iface name — имя интерфейса;
  • ip — ip адрес интерфейса.
    - если указанный в конфиге в разделе via ip-адрес не существует, он не обрабатывается (пропускается)
    - если указан верный ip, то он прикрепляется для регистрации в заголовок Via
    - при отсутствии интерфейса в конфиге в via при мастер-регистрации указывается bind-address из конфига, при при не-мастер регистрации поведение прежнее.

3. Запуск медиасервера

Запуск медиасервера в виде сервиса (по умолчанию)

Для работы сервис использует конфигурацию из файлов:

/etc/ecss/ecss-media-server/config.xml

/etc/ecss/ecss-media-server/conf.d/default.xml

Подробнее о настройках — в разделе "Настройка конфигурационного файла MSR".

При изменении конфигурации необходимо обязательно перезапустить сервис ecss-media-server.

Запуск сервиса:

sudo systemctl start ecss-media-server.service

Остановка сервиса:

sudo systemctl stop ecss-media-server.service

Перезапуск сервиса:

sudo systemctl restart ecss-media-server.service

Запуск медиасервера вручную в виде приложения

Описание опций команды ecss-media-server [options].

[options] — опция команды ecss-media-server, принимает значения:

• --help — вывод помощи;
• --dbg — вывод логов на экран;
• --version — вывод информации о версии;
• --daemon — запуск процесса в фоновом режиме, все пути должны быть абсолютными;
• --noiput — не пытаться читать какие-либо входные данные;
• --config=file — настройка пути к конфигурационному XML-файлу;
• --analyze=script — синтаксический и семантический анализ IVR-скрипта.

Пример:

ecss-media-server --config=/home/ssw/config.xml

Запуск более одного медиасервера на одном хосте через systemd-сервис

В состав deb пакета ecss-media-server был добавлен сервис 'ecss-media-server@', который позволяет запускать множество экземпляров медиасервера.

Также для медиасервера был добавлен предсконфигурированный файл конфигурации (с выключенной поддержкой видео) с именем config-without-video.xml. 
После установки deb пакета располагается по пути: /etc/ecss/ecss-media-server. Хотя данный файл предсконфигурирован, но для каждого конкретного случая его нужно донастраивать/перенастраивать:

• секция transport
  • параметры bind-addr и port
• секция accounts -> секция dynamic
  • параметры msr_name и realm
• секция pbyte -> секция mcc
  • параметры bind-addr и port.

Конфигурационные файлы

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

Отдельно нужно обратить внимание на секцию media: параметры port-start и port-range не должны пересекаться с параметрами уже запущенных msr-ов, иначе в ходе работы на одном из msr-ов могут возникнуть ошибки, ввиду того что данные порты уже будут заняты. Также стоит обратить внимание на секцию mcc, параметр port не должен пересекаться с параметрами уже запущенных msr-ов по той же причине. Параметр log-path должен быть уникальным для каждого MSR. Если путь, указанный в log-path, еще не существует, оператор SSW должен прописать его вручную (пользователь для директории с логами должен быть ssw:ssw).

Включение и запуск множества экземпляров сервиса ecss-media-server@

В systemd есть возможность запускать множество экземпляров сервиса, но предварительно данные экземпляры нужно включить.
Включение:

sudo systemctl enable ecss-media-server@<имя_запускаемого_экземпляра>

Запуск:

sudo systemctl start ecss-media-server@<имя_запускаемого_экземпляра>

В данном случае этому медиасерверу будет соответствовать файл конфигурации с именем config-<имя_запускамого_экземпляра>.xml, располагаемый по пути /etc/ecss/ecss-media-server/.

Например, включенному и запущенному экземпляру msr-а с именем without-video:

sudo systemctl enable ecss-media-server@without-video
Created symlink /etc/systemd/system/multi-user.target.wants/ecss-media-server@without-video.service → /lib/systemd/system/ecss-media-server@.service.

sudo systemctl start ecss-media-server@without-video

будет соответствовать файл конфигурации с именем config-without-video.xml расположенный по пути /etc/ecss/ecss-media-server/.
Для каждого экземпляра медиасервера должен быть сконфигурирован свой файл конфигурации медиасервера.

Убедиться, что экземпляр ecss-media-server@without-video запустился можно следующей командой:

ecss1@ssw 05:04:58 ~$ sudo systemctl status ecss-media-server@without-video
● ecss-media-server@without-video.service - daemon ecss-media-server-without/video of ecss-10
   Loaded: loaded (/etc/systemd/system/ecss-media-server@.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-12-07 08:07:58 +07; 4s ago
 Main PID: 12144 (ecss-media-serv)
    Tasks: 19 (limit: 4915)
   CGroup: /ecss.slice/ecss-media-server@without-video.service
           └─12144 /usr/bin/ecss-media-server --config=/etc/ecss/ecss-media-server/config-without-video.xml --noinput

дек 07 08:07:58 ssw systemd[1]: Started daemon ecss-media-server-without/video of ecss-10.
дек 07 08:07:59 ssw ecss-media-server[8867]: WARNING: no real random source present!

4. Настройка ECSS-10 для работы с медиасервером

Настройка параметров Registrar-сервера

/system/media/registrar/clean common all            
All common parameters is clean.

/system/media/registrar/info
 Common parameters:
┌───────────────────────────┬───────┐
│         Parameter         │ Value │
├───────────────────────────┼───────┤
│ registration-timeout, sec │   180 │
└───────────────────────────┴───────┘
 Private parameters:
┌─────────────┬─────────┬───────────┬────────────┬─────────────┐
│    Node     │ Status  │ Is-active │ Listen-ip  │ Listen-port │
├─────────────┼─────────┼───────────┼────────────┼─────────────┤
│ core1@ecss2 │ active  │ true      │ 10.0.20.72 │        5000 │
│ core1@ecss1 │ active  │ true      │ 10.0.20.71 │        5000 │
└─────────────┴─────────┴───────────┴────────────┴─────────────┘

Где

/system/media/registrar/set common registration-timeout 60
Common parameter registration-timeout set to 60.

/system/media/registrar/set private core1@ecss1 listen-port 5001
Private parameter listen-port set to 5001 at node core1@ecss1.

Проверка контрольной коннекции

ecss_zmq_transport connection status:
┌─────────────┬───────────┬─────────┬────────┐
│Connection ID│   Node    │ Status  │IsActive│
├─────────────┼───────────┼─────────┼────────┤
│c5b9d8       │core1@ecss1│connected│true    │
│             │core1@ecss2│connected│true    │
│22abcd       │core1@ecss1│connected│true    │
│             │core1@ecss2│connected│true    │
└─────────────┴───────────┴─────────┴────────┘

Добавление медиаресурсов

/system/media/resource/declare * contact net.20@msr.ecss1  default local true

Declared media resources
┌─────────────┬──────────────────┬────────┬─────────┬───────┐
│    Node     │     Contact      │ Active │   Zone  │  Site │
├─────────────┼──────────────────┼────────┼─────────┼───────┤
│ core1@ecss1 │ net.20@msr.ecss1 │ true   │ default │ local │
│ core1@ecss2 │ net.20@msr.ecss1 │ true   │ default │ local │
└─────────────┴──────────────────┴────────┴─────────┴───────┘

/system/media/resource/info core1@ecss1 net.20@msr.ecss1
  Media resource specific for node core1@ecss1:
┌─┬─────────────────┬─────────────────────┐
│F│    Parameter    │        Value        │
├─┼─────────────────┼─────────────────────┤
│r│ Contact         │ net.20@msr.ecss1    │
│r│ Status          │ registered          │
│r│ Cc-status       │ connected           │
│r│ Cc-status uptime│ 1 04:22:19          │
│r│ Cc-id           │ fbd880              │
│r│ Address         │ 10.0.20.71:5700     │
│r│ Register time   │ 2025/02/04 14:57:39 │
│r│ Expired         │ 81                  │
│r│ Iface           │ net.20(10.0.20.71)  │
│ │ Active          │ true                │
│ │ Zone            │ default             │
│ │ Site            │ local               │
│r│ MSR version     │ 3.14.15.243         │
│r│ MSR load        │ 0                   │
│r│ MSR perf coef   │ 1.0                 │
└─┴─────────────────┴─────────────────────┘

Legend:
Column F - means Flag, values r - flag for readonly parameter

/system/media/resource/list all
  All media resource selected list specific:
┌─────────────┬───────────┬─────────────┬───────────┬──────┬────────┬───────────┬────────────┬─────────────────┬────────┬────────────┬────────┬─────────┬───────┬──────────────────┬────────────┬─────────┐
│    Node     │    MSR    │     MSR     │    MSR    │ MSR  │ Cc-id  │ Cc-status │ Cc-uptime  │   Cc-address    │ Iface  │   Iface    │ Active │  Zone   │ Site  │     Contact      │   Status   │ Expired │
│             │           │   version   │ perf coef │ load │        │           │            │                 │  name  │    addr    │        │         │       │                  │            │         │
├─────────────┼───────────┼─────────────┼───────────┼──────┼────────┼───────────┼────────────┼─────────────────┼────────┼────────────┼────────┼─────────┼───────┼──────────────────┼────────────┼─────────┤
│ core1@ecss1 │ msr.ecss1 │ 3.14.15.243 │       1.0 │    0 │ fbd880 │ connected │ 1 04:24:46 │ 10.0.20.71:5700 │ net.20 │ 10.0.20.71 │ true   │ default │ local │ net.20@msr.ecss1 │ registered │     174 │
│             │ msr.ecss2 │ 3.14.15.243 │       1.0 │    0 │ 3f6496 │ connected │ 1 04:24:46 │ 10.0.20.72:5700 │ net.20 │ 10.0.20.72 │ true   │ default │ local │ net.20@msr.ecss2 │ registered │     176 │
│ core1@ecss2 │ msr.ecss1 │ 3.14.15.243 │       1.0 │    0 │ fbd880 │ connected │ 1 04:24:46 │ 10.0.20.71:5700 │ net.20 │ 10.0.20.71 │ true   │ default │ local │ net.20@msr.ecss1 │ registered │     175 │
│             │ msr.ecss2 │ 3.14.15.243 │       1.0 │    0 │ 3f6496 │ connected │ 1 04:24:46 │ 10.0.20.72:5700 │ net.20 │ 10.0.20.72 │ true   │ default │ local │ net.20@msr.ecss2 │ registered │     176 │
└─────────────┴───────────┴─────────────┴───────────┴──────┴────────┴───────────┴────────────┴─────────────────┴────────┴────────────┴────────┴─────────┴───────┴──────────────────┴────────────┴─────────┘

/system/media/resource/purge core1@ecss1              
Purged contact list at node core1@ecss1:
 net.20@msr.ecss1
 net.20@msr.ecss2

/system/media/resource/remove * contact net.20@msr.ecss1
Media resource with contact(net.20@msr.ecss1) deleted at nodes:
   core1@ecss2
   core1@ecss1

/system/media/resource/set core1@ecss1 net.20@msr.ecss1 active true         
  Media resource:
┌─────────────┬──────────────────┬──────────┬───────┐
│    Node     │     Contact      │ Property │ Value │
├─────────────┼──────────────────┼──────────┼───────┤
│ core1@ecss1 │ net.20@msr.ecss1 │ active   │ true  │
└─────────────┴──────────────────┴──────────┴───────┘

/system/media/resource/status
  Status of active media resource list:
┌─────────────┬───────────┬─────────────┬───────────┬──────────────┬────────────────────────┬───────────────────┬────────┬────────────┬─────────┐
│    Node     │    MSR    │     MSR     │    MSR    │   MSR load   │           Cc           │       Iface       │ Active │   Status   │ Expired │
│             │           │   version   │ perf coef │ calls(level) │     status(uptime)     │     name:addr     │        │            │         │
├─────────────┼───────────┼─────────────┼───────────┼──────────────┼────────────────────────┼───────────────────┼────────┼────────────┼─────────┤
│ core1@ecss1 │ msr.ecss1 │ 3.14.15.243 │       1.0 │      -       │ connected (1 04:46:10) │ net.20:10.0.20.71 │ true   │ registered │      89 │
│             │ msr.ecss2 │ 3.14.15.243 │       1.0 │      -       │ connected (1 04:46:10) │ net.20:10.0.20.72 │ true   │ registered │      91 │
│ core1@ecss2 │ msr.ecss1 │ 3.14.15.243 │       1.0 │      -       │ connected (1 04:46:10) │ net.20:10.0.20.71 │ true   │ registered │      90 │
│             │ msr.ecss2 │ 3.14.15.243 │       1.0 │      -       │ connected (1 04:46:10) │ net.20:10.0.20.72 │ true   │ registered │      91 │
└─────────────┴───────────┴─────────────┴───────────┴──────────────┴────────────────────────┴───────────────────┴────────┴────────────┴─────────┘

Настройка таймеров контрольной коннекции

/system/mediactrl/clean mediactrl_keepalive_timeout
Property "mediactrl_keepalive_timeout" values successfully restored

/system/mediactrl/info
┌─────────────────────────────┬─────┐
│          Property           │Value│
├─────────────────────────────┼─────┤
│mediactrl_keepalive_timeout  │10   │
│mediactrl_transaction_timeout│20   │
│msr_ban_end_timeout          │1000 │
└─────────────────────────────┴─────┘

/system/mediactrl/set mediactrl_keepalive_timeout 5
Property "mediactrl_keepalive_timeout" successfully changed from: 
10
   to
5.

Конфигурирование распределенного медиасервера

Описание

Распределенность медиасервера обеспечивает следующие возможности:

• Масштабирование количества медиаканалов за счет использования нескольких медиасерверов;
• Обмен медиатрафиком между абонентами, представленными в разных сетях-зонах;
• Региональное тяготение — минимизация межсетевого трафика медиаданных и снижение латентности за счет близкого расположения ресурса медиасервера к источникам/потребителям медиатрафика;
• Специализация медиаресурсов на медиасерверах (медиасервера могут отличаться своими возможностями).

Для функционирования схемы система ECSS-10 должна обладать информацией о доступных ей медиасерверах и их возможностях. Механизм медиасерверов, используемых для обнаружения, должен быть динамическим, автоматически подстраиваться к изменениям параметров сети, реагировать на появление/исчезновение медиасервера/ECSS-10.

Используемая схема обнаружения и информирования о статусе/возможностях медиасерверов основана на стандартной SIP-регистрации (метод SIP REGISTER). В данном сообщении в ядро ECSS-10 передается вся необходимая служебная информация.

Согласно типовой схемы, подключения к ECSS-10 осуществляется в разных VLAN. Задача ECSS-10 обеспечить коммутацию медиапотоков между абонентами этих VLAN. Для коммутации медиапотоков между абонентами одного VLAN терминация трафика на медиаресурсе ECSS-10 (медиасервере) не является обязательной. Для абонентов разных VLAN необходимо:

1. Терминировать медиатрафик из разных VLAN в медиасервере;
2. Обеспечить "перекладку" медиапакетов из одного VLAN в другой.

На рисунке 1 указаны требования к функционалу медиасервера по формированию точки приема медиатрафика во всех VLAN, которые заведены на него.

Рисунок 1 — Требования к функционалу медиасервера

Типовой случай распределенного медиасервера будет выглядеть следующим образом:

Рисунок 2 — Типовой случай распределенного медиасервера

Географическая распределенность

ECSS-10 должен корректно выбирать медиасервер. Под корректностью подразумевается уровень его загруженности (равномерное использование доступных ресурсов), а также учет его территориального расположения (распределение с учетом географии пользователей). Уровень загрузки ресурсов вычисляется на основании данных о параметрах медиасервера (сообщение уровня загрузки CPU в каждом сообщении от MSR к SIP-серверу).

Территориальную принадлежность ECSS-10 определяет самостоятельно путем тегирования аккаунтов UA медиасервера. Служебным UA для медиасервера ставится в соответствие имя сайта (site) — географическая зона, которую может обслуживать данный контакт медиасервера. Пользовательским окончаниям и транкам также задается географическая областью путем установки параметра site. Для проключения медиа-потока ECSS-10 использует медиасервер с сайтом минимально удаленным от целевого.
Сетка взаимопритяжений/дистанций (матрица связности) сайтов задается в конфигурации ECSS-10.

Выбор медиаресурса

1. Выбор осуществляется среди зарегистрированных и активированных медиаресурсов.
2. При выборе подходящего медиаресурса учитывается Zone (NID) и site.
3. Сначала список доступных медиаресурсов фильтруется на основании параметра Zone (NID), затем выбирается ресурс с максимальным тяготением к site ресурса (минимальное "расстояние").
4. При выборе медиаресурса для терминирующей стороны предпочтение отдается выделению точки "приземления" медиатрафика на том же медиасервере, который использовался для "приземления" медиатрафика вызывающей стороны. Если использование медиасервера вызывающей стороны невозможно (в силу отличных Zone (NID) вызывающего или вызываемого абонента), то медиаресурс терминирующей стороны выбирается по тому же алгоритму, что и для вызывающей стороны (с учетом Zone (NID) и site терминирующей стороны).

Матрица связности

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

Пример
Вызов инициируется абонентом site1. Для обслуживания вызова система по матрице связности ищет медиаресурсы с минимальным расстоянием от сайта инициатора вызова.
Значения, показывающие "расстояние" между сайтами, являются условными и фактически задают стоимость использования медиаресурса выбранного сайта для обслуживания вызова от абонента.
Расстояние до медиаресурсов сайта, к которому относится абонент по умолчанию, принимается равным 0, но может быть изменено. Это сделано для того чтобы можно было на время вывести MSR из работы, например, для обновления. 
Если установлено расстояние между сайтами 0 — это означает, что медиаресурсы сайтов равноправны.
Если абонентам одного сайта необходимо запретить использовать медиаресурса другого сайта, то нужно установить расстояние между этими сайтами равное бесконечности — infinity.

Алгоритм определения ресурсов

Алгоритм, который использует ядро для поиска подходящего MSR, эквивалентен следующему:

1. Для заданного UA пользователя (далее просто UA), который будет парковаться на MSR, определяются связанные с ним параметры Zone, site, и опционально msr_id (если информация о нем присутствует);
2. Для ядра, на котором обслуживается текущий call-процесс, выполняется поиск зарегистрированных (поле Status = registered), административно разрешенных (поле Active = true), c зоной (Zone) UA контактов MSR;
3. Из найденных контактов выбираются те, которые соответствуют известному msr_id (если он все таки задан, в противном случае подходят все контакты предыдущего шага);

4. Далее выбранные контакты ранжируются по расстоянию между site UA и site самого контакта в соответствии с матрицей связанности:

   /system/media/site/matrix 
   ┌───────────┬───┬────┬────┬────┬───┐
   │ Site-name │ # │ 1  │ 2  │ 3  │ 4 │
   ├───────────┼───┼────┼────┼────┼───┤
   │ local     │ 1 │  0 │ 10 │ 20 │   │
   │ site_102  │ 2 │ 10 │    │    │   │
   │ site_103  │ 3 │ 20 │    │    │   │
   │ site_104  │ 4 │    │    │    │ 0 │
   └───────────┴───┴────┴────┴────┴───┘
   
   Legend:
    empty distance - infinity distance between sites.

   Выбираются контакты с наименьшим расстоянием;

5. Контакты, полученные на предыдущем шаге, сортируем с удалением дубликатов по имени msr (поле msr_name). Получаем контакты с уникальными msr-ами. Контакты содержат информацию о загруженности msr-а и коэффициенте производительности msr-а;
6. На основе контактов, полученных на предыдущем шаге, строится интервальная таблица загруженности msr с учетом коэффициента производительности:
   1. Верхняя граница таблицы (table_upper_bound) выставляется в 0, помещаем все контакты в очередь;
   2. Если очередь не пуста, то забираем контакт из очереди:

      • Для контакта выставляем нижнюю границу(con_bottom_bound) по формуле:

        con_bottom_bound = table_upper_bound

      • Для контакта формируем верхнюю границу(con_upper_bound) по формуле:

        (100 - con_msr_load) * con_msr_performance_coefficient

      • Выставляем верхнюю границу таблицы(table_upper_bound) по формуле:

        table_upper_bound = table_upper_bound + con_upper_bound

      • Кладем контакт в список;
      • Переход к пункту 6.2;
   3. Если контактов в списке нет, то такое плечо UA релизится с соответствующим cause (msr не найден);
   4. Генерируем случайное число от 0 до table_upper_bound;
   5. В списке находим контакт, в границы которого попадает сгенерированное число. Найденный контакт используется для парковки данного UA на MSR.

Пример с 5 шага:

Шаг 5:
  Есть контакты con_1@msr_1, con_2@msr_1, con_1@msr_2, con_1@msr_3.
Шаг 6:
  Есть контакты con_1@msr_1, con_1@msr_2, con_1@msr_3.
  msr_1 загружен на 55%, коэф. производительности 1.0.
  msr_2 загружен на 40%, коэф. производительности 0.9.
  msr_3 загружен на 60%, коэф. производительности 1.2.

Шаг 6.1
  table_upper_bound = 0,
  queue = [con_1@msr_1, con_1@msr_2, con_1@msr3]

Шаг 6.2
  take from queue = con_1@msr_1

Шаг 6.2.1
  con_bottom_bound = 0

Шаг 6.2.2
  con_upper_bound = (100 - 55) * 1.0 = 45

Шаг 6.2.3
  table_upper_bound = 0 + 45 = 45

Шаг 6.2.4
   put to list = con_1@msr_1(0-45)

Шаг 6.3
   переход на шаг 4.2

Шаг 6.2
  take from queue = con_1@msr_2

Шаг 6.2.1
  con_bottom_bound = 45

Шаг 6.2.2
  con_upper_bound = (100 - 40) * 0.9 = 56

Шаг 6.2.3
  table_upper_bound = 45 + 56 = 101

Шаг 6.2.4
   put to list = con_1@msr_2(45-101)

Шаг 6.2
  take from queue = con_1@msr_3

Шаг 6.3
   переход на шаг 6.2

Шаг 6.2.1
  con_bottom_bound = 101

Шаг 6.2.2
  con_upper_bound = (100 - 60) * 1.2 = 48

Шаг 6.2.3
  table_upper_bound = 101 + 48 = 149

Шаг 6.2.4
   put to list = con_1@msr_3(101-149)

Шаг 6.4
   list = [con_1@msr_1(0-45), con_1@msr_2(45-101), con_1@msr_3(101-149)]
   generate 58

Шаг 6.5
   found con_1@msr_2(45-101)

Найден контакт con_1@msr_2 (msr c именем msr_2).

Пример настройки и парковки вызова

MSR регистрируют контакты со следующими параметрами:

Имеющаяся следующую матрицу связности:

Абонент UA1 хочет установить разговор с абонентом UA2, при этом они имеют следующие параметры:

Сначала паркуется плечо UA1.
Из списка активных контактов MSR выбираем все, которые принадлежат зоне rtk:

Список контактов остается прежним.
Вычисляем расстояние между ua site: okrujnaya и сайтом каждого из контактов. Имеем:

Контакты ранжированы в порядке увеличения дистанции. Берем первый из них и используем его для парковки UA1:
name: msr1_eth0, msr_id:1

Парковка второго плеча: ua2.
Он принадлежит другой зоне, поэтому список контактов после выбора по зоне будет выглядеть так:

На предыдущем шаге у нас определен msr_id=1.

С учетом msr_id получаем новый список контактов:

Далее вычисляем расстояние между ua2 site: molodeju и r_kalininsky.

В текущем примере используется довольно простая схема с MSR, поэтому для представленных условий у нас остался лишь один контакт.
Его и используем для парковки ua2.

Так как оба плеча сумели запарковаться на MSR, абоненты смогут обмениваться rtp-трафиком.

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

Управление географическими зонами обслуживания медиасервера

admin@mycelium1@ecss1:/$ system/media/site/declare remote_side    
Site: remote_side.
 Created successfully.

admin@mycelium1@ecss1:/$ system/media/site/distance local remote_side 64           
Distance between local and remote_side changed to: 64.

List of all sites:
 local
 remote
 remote_side

admin@mycelium1@ecss1:/$ system/media/site/matrix local remote_side remote              
┌─────────────┬───┬───┬───┬────┐
│    site     │ # │ 1 │ 2 │ 3  │
├─────────────┼───┼───┼───┼────┤
│ local       │ 1 │ 0 │ r │ 64 │
│ remote      │ 2 │ r │ 0 │  r │
│ remote_side │ 3 │ r │ r │  0 │
└─────────────┴───┴───┴───┴────┘

The site of row is correspond to site of iface(domain/<domain>/iface).
The site of column is correspond to site of contact(system/media/resource/list).

Legend:
  r - the distance is present only when there is another subscriber with a distance not equal to the value r(relation) to a given msr.
  empty distance - infinity distance between sites.

admin@mycelium1@ecss1:/$ system/media/site/remove remote_side  
Site: remote_side.
 Removed successfully.

Коэффициент производительности

Для каждого медиасервера в системе можно установить нужный коэффициент производительности. При распределении медиатрафика этот коэффициент будет учитываться, и нагрузка между разными медиасерверами будет делиться пропорционально данным значениям.  Коэффициент (любое положительное целое или дробное число) устанавливается командой system/media/msr/set.

Примеры:

Установить для msr_1 коэффициент производительности 2:

/system/media/msr/set --performance_coefficient 2 --msr_name msr_1        
Success: Property has been set for msr_1.

Просмотр:

/system/media/msr/info --ccid
Default:
┌─────────────────────────────────┬─────────┬────────────────────────────────────────────────────────────────────────────────┐
│            Property             │  Value  │                                  Description                                   │
├─────────────────────────────────┼─────────┼────────────────────────────────────────────────────────────────────────────────┤
│check_cp                         │false    │Check call process by UPDATE from msr?                                          │
│check_cp_timeout                 │200      │Timeout of wait response from call process, ms                                  │
│close_cc                         │true     │Do close control connection to msr after registration expires from msr?         │
│cps_limit                        │50       │Maximum number(limit) of CPS(Calls per Second) distributed to msr, from 0 to 50 │
│critical_load                    │100      │If the load of msr more or equal this value, msr will no longer be selected to h│
│                                 │         │andle calls. Percent, from 0 to 100                                             │
│is_max_calls_limit_reached       │false    │Check maximum number of calls on MSR has been reached?                          │
│is_subscribe_to_call_count       │false    │Is subscribe to call count on msr?                                              │
│'max-calls'                      │4096     │Maximum number(limit) of calls that MSR supports. The value received from MSR.  │
│'media/chatroom'                 │audio    │Media of the chatroom                                                           │
│'media/conference'               │audio    │Media of the network conference                                                 │
│'media/meetme'                   │audio    │Media of the meet me conference                                                 │
│'media/teleconference'           │audio    │Media of the teleconference                                                     │
│'mixer-clock-rate'               │8000     │Audio mixing frequency on MSR. The value received from MSR. Used in SORM3       │
│performance_coefficient          │1.0      │Msr performance coefficient                                                     │
│subscribe_to_call_count_expires  │60       │Expires of subscribe to call count on msr, s                                    │
│zmq_connection_response_timeout  │500      │Connection response timeout, ms                                                 │
│zmq_connection_update_ack_timeout│500      │Connection update ack timeout, ms                                               │
│zmq_connection_update_timeout    │1000     │Connection update timeout, ms                                                   │
│zmq_reconnect_timeout            │1000     │Reconnect timeout, ms                                                           │
│zmq_src_port                     │undefined│Source port of control connection                                               │
└─────────────────────────────────┴─────────┴────────────────────────────────────────────────────────────────────────────────┘
MSR:
┌─────────┬───────────┬─────┐
│   MSR   │ Property  │Value│
├─────────┼───────────┼─────┤
│msr.ecss1│'max-calls'│4048 │
│msr.ecss2│'max-calls'│4048 │
└─────────┴───────────┴─────┘
CCID:
┌──────┬─────────┐
│ CCID │   MSR   │
├──────┼─────────┤
│3f6496│msr.ecss2│
│fbd880│msr.ecss1│
└──────┴─────────┘

Также данные значения можно увидеть при выводе списка медиаресурсов:

/system/media/resource/list active
  Active media resource selected list specific:
┌─────────────┬───────────┬─────────────┬───────────┬──────┬────────┬───────────┬───────────┬─────────────────┬────────┬────────────┬────────┬─────────┬───────┬──────────────────┬────────────┬─────────┐
│    Node     │    MSR    │     MSR     │    MSR    │ MSR  │ Cc-id  │ Cc-status │ Cc-uptime │   Cc-address    │ Iface  │   Iface    │ Active │  Zone   │ Site  │     Contact      │   Status   │ Expired │
│             │           │   version   │ perf coef │ load │        │           │           │                 │  name  │    addr    │        │         │       │                  │            │         │
├─────────────┼───────────┼─────────────┼───────────┼──────┼────────┼───────────┼───────────┼─────────────────┼────────┼────────────┼────────┼─────────┼───────┼──────────────────┼────────────┼─────────┤
│ core1@ecss1 │ msr.ecss1 │ 3.14.15.243 │       1.0 │    0 │ fbd880 │ connected │ 04:09:14  │ 10.0.20.71:5700 │ net.20 │ 10.0.20.71 │ true   │ default │ local │ net.20@msr.ecss1 │ registered │      93 │
│             │ msr.ecss2 │ 3.14.15.243 │       1.0 │    0 │ 3f6496 │ connected │ 04:09:15  │ 10.0.20.72:5700 │ net.20 │ 10.0.20.72 │ true   │ default │ local │ net.20@msr.ecss2 │ registered │      92 │
│ core1@ecss2 │ msr.ecss1 │ 3.14.15.243 │       1.0 │    0 │ fbd880 │ connected │ 04:09:18  │ 10.0.20.71:5700 │ net.20 │ 10.0.20.71 │ true   │ default │ local │ net.20@msr.ecss1 │ registered │      89 │
│             │ msr.ecss2 │ 3.14.15.243 │       1.0 │    0 │ 3f6496 │ connected │ 04:09:20  │ 10.0.20.72:5700 │ net.20 │ 10.0.20.72 │ true   │ default │ local │ net.20@msr.ecss2 │ registered │      87 │
└─────────────┴───────────┴─────────────┴───────────┴──────┴────────┴───────────┴───────────┴─────────────────┴────────┴────────────┴────────┴─────────┴───────┴──────────────────┴────────────┴─────────┘

Уровень загрузки медиасервера

Механизм информирования ядра о степени загруженности MSR реализован через подписки. Команды по управлению такими подписками приведены справочнике команд CLI — /system/media/msr/subscription/.

Также в конфигурационном файле msr предусмотрены настройки, отображенные по следующей ссылке.

Видео-заставка/обои вызова на парковке/ожидании

По умолчанию в качестве источника видео при парковке медиа на msr используется статическая картинка. В конфигурационном файле медиасервера этот параметр настраивается в секции media:

dummy-video-src="/usr/share/ecss-media-server/video/dummy_video.yuv"

Для создания собственной статической или видео-заставки можно использовать утилиты ffmpeg и gstreamer.

Пакеты имеются в репозитории Ubuntu:

sudo aptitude update
sudo aptitude install ffmpeg

sudo aptitude install gstreamer0.10-tools gstreamer0.10-plugins-base gstreamer0.10-plugins-good
sudo add-apt-repository ppa:mc3man/gstffmpeg-keep
sudo aptitude update
sudo aptitude install gstreamer0.10-ffmpeg

Статическая картинка

Изображение должно быть в формате YUV420 (цветовая модель сырого кадра видео) и иметь расширение *.yuv.  Размер до 1280×720, но лучше использовать меньшие размеры, например 352×288 или 704×576.

Пример конвертации:

bsk@bsk:~$ ffmpeg -i input.png -f rawvideo -pix_fmt yuv420p output.yuv
ffmpeg version 2.8.15-0ubuntu0.16.04.1 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.10) 20160609
  configuration: --prefix=/usr --extra-version=0ubuntu0.16.04.1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 60.100 / 56. 60.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 40.101 /  5. 40.101
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
Input #0, png_pipe, from 'input.png':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: png, rgb24(pc), 816x460 [SAR 3779:3779 DAR 204:115], 25 tbr, 25 tbn, 25 tbc
Output #0, rawvideo, to 'output.yuv':
  Metadata:
    encoder         : Lavf56.40.101
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 816x460 [SAR 1:1 DAR 204:115], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.60.100 rawvideo
Stream mapping:
  Stream #0:0 -> #0:0 (png (native) -> rawvideo (native))
Press [q] to stop, [?] for help
frame=    1 fps=0.0 q=-0.0 Lsize=     550kB time=00:00:00.04 bitrate=112608.0kbits/s    
video:550kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

Видео-заставка

Видеофайл также должен быть в "сыром" YUV420 формате и иметь расширение .video.

Пример конвертации:

bsk@bsk:~$ gst-launch-0.10 -v filesrc location=./input_video.mp4 ! qtdemux name=demux demux.video_00 ! ffdec_h264 ! \
>  video/x-raw-yuv,width=1280,height=720,format='(fourcc)'I420 ! \
>  videoscale method=3 ! video/x-raw-yuv,width=720,height=480,format='(fourcc)'I420 ! \
>  videorate max-rate=15 ! filesink location=./output.video

Установка конвейера в состояние PAUSED...
Подготовка конвейера (PREROLL)...
/GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:sink: caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3.1, profile=(string)high, codec_data=(buffer)0164001fffe1001f6764001fac2ca4014016ec054808080a000003000200000300793b42c5a24001000568eb735250, width=(int)1280, height=(int)720, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:src: caps = video/x-raw-yuv, width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(fourcc)I420, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw-yuv, width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(fourcc)I420, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw-yuv, width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(fourcc)I420, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstVideoScale:videoscale0.GstPad:src: caps = video/x-raw-yuv, width=(int)720, height=(int)480, format=(fourcc)I420, framerate=(fraction)30/1, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)32/27
/GstPipeline:pipeline0/GstVideoScale:videoscale0.GstPad:sink: caps = video/x-raw-yuv, width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(fourcc)I420, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:src: caps = video/x-raw-yuv, width=(int)720, height=(int)480, format=(fourcc)I420, framerate=(fraction)30/1, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)32/27
/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:sink: caps = video/x-raw-yuv, width=(int)720, height=(int)480, format=(fourcc)I420, framerate=(fraction)30/1, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)32/27
/GstPipeline:pipeline0/GstVideoRate:videorate0.GstPad:src: caps = video/x-raw-yuv, width=(int)720, height=(int)480, format=(fourcc)I420, framerate=(fraction)15/1, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)32/27
/GstPipeline:pipeline0/GstVideoRate:videorate0.GstPad:sink: caps = video/x-raw-yuv, width=(int)720, height=(int)480, format=(fourcc)I420, framerate=(fraction)30/1, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)32/27
/GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = video/x-raw-yuv, width=(int)720, height=(int)480, format=(fourcc)I420, framerate=(fraction)15/1, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)32/27
Конвейер подготовлен (PREROLLED)...
Установка конвейера в состояние PLAYING...
New clock: GstSystemClock
Получен маркер EOS («конец потока») от элемента «pipeline0».
Execution ended after 11407407262 ns.
Установка конвейера в состояние PAUSED...
Установка конвейера в состояние READY...
/GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstVideoRate:videorate0.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstVideoRate:videorate0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstVideoScale:videoscale0.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstVideoScale:videoscale0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:src: caps = NULL
/GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstQTDemux:demux.GstPad:audio_00: caps = NULL
/GstPipeline:pipeline0/GstQTDemux:demux.GstPad:video_00: caps = NULL
Установка конвейера в состояние NULL...
Освобождение конвейера...

Готовые видеозаставки находятся в /var/lib/ecss/ecss-media-server.

Примеры настройки

Система с одним сервером

Условия

Медиасервер установлен на том же сервере, что и SSW.
Используется один интерфейс — bond1.2, адрес 192.168.2.21.

Настройки

Конфигурационный файл для таких условий нужно привести к виду (нужно прописать адрес 192.168.2.21 вместо 127.0.0.1):

<?xml version="1.0" encoding="utf-8"?>
<config date="05:00:58 28.01.2021">
  <general log-level="3" log-rotate="yes" max-calls="8192" max-in-group="512" load-sensor="media" load-delta="10" spool-dir-size="100M" log-name="msr.log" log-path="/var/log/ecss/media-server" use-srtp="disabled" suspicious-mode="no"/>
  <transport bind-addr="192.168.2.21" port="5040" transport="udp+tcp"/>
  <media mixer-clock-rate="8000" use-vad="no" cng-level="0" jb-size="60" rtcp-timeout="0" rtp-timeout="350" udp-src-check="no" cn-multiplier="3" port-start="12000" port-range="2048" tias-in-sdp="no" thread-cnt="2" silence-threshold="-30" dtmf-flash-disable="no" video-dscp="0" other-dscp="0" dummy-video-src="/usr/share/ecss-media-server/video/dummy_video.yuv" video-enc-width="1280" video-enc-height="720" finalsilence="1000" rtcp-stat-dump="yes"/>
  <codec pcma="1" pcmu="2" ilbc="0" gsm="0" g722="3" g729="0" speex="0" l16="0" g7221="0" opus="0" h264="1" h263-1998="2" t38="1" tel-event-pt="0"/>
  <accounts>
    <dynamic msr_name="msr_1" realm="sip:192.168.2.21:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password"/>
  </accounts>
  <pbyte>
    <mcc bind-addr="192.168.2.21" port="5700"/>
  </pbyte>
  <conf_dir path="/etc/ecss/ecss-media-server/conf.d"/>
  <rtp>
    <auto addr-v4=""/>
  </rtp>
</config>

В настройках ECSS-10 нужно указать адрес для приема регистраций (в целях безопасности, т.к. по умолчанию соединения принимаются на всех адресах — 0.0.0.0):

/system/media/registrar/set private core1@ecss1 listen-ip 192.168.2.21
Private parameter listen-ip set to 192.168.2.21 at node core1@ecss1.

Далее следует задекларировать медиаресурсы на интерфейсе bond1.2:

/system/media/resource/declare core1@ecss1 iface msr_1 bond1.2 default local true

Система с резервированием на двух серверах

Медиасервер в целях резервирования медиаресурсов должен быть установлен на каждом сервере, на котором установлено ECSS-10.

Условия

Сервер 1. Интерфейс — eth0, адрес 192.168.2.21
Сервер 2. Интерфейс — eth0, адрес 192.168.2.22

Не используйте плавающие (keepalive) адреса для медиасервера.

Настройки

На первом сервере в конфигурационном файле /etc/ecss/ecss-media-server/config.xml в качестве адреса transport bind-addr и mcc bind-addr нужно указать адрес этого же сервера, т.е. 192.168.2.21. В секции аккаунтов должны быть прописаны динамические аккаунты для первого сервера и для второго.

<?xml version="1.0" encoding="utf-8"?>
<config date="05:00:58 28.01.2021">
  <general log-level="3" log-rotate="yes" max-calls="8192" max-in-group="512" load-sensor="media" load-delta="10" spool-dir-size="100M" log-name="msr.log" log-path="/var/log/ecss/media-server" use-srtp="disabled" suspicious-mode="no"/>
  <transport bind-addr="192.168.2.21" port="5040" transport="udp+tcp"/>
  <media mixer-clock-rate="8000" use-vad="no" cng-level="0" jb-size="60" rtcp-timeout="0" rtp-timeout="350" udp-src-check="no" cn-multiplier="3" port-start="12000" port-range="2048" tias-in-sdp="no" thread-cnt="2" silence-threshold="-30" dtmf-flash-disable="no" video-dscp="0" other-dscp="0" dummy-video-src="/usr/share/ecss-media-server/video/dummy_video.yuv" video-enc-width="1280" video-enc-height="720" finalsilence="1000" rtcp-stat-dump="yes"/>
  <codec pcma="1" pcmu="2" ilbc="0" gsm="0" g722="3" g729="0" speex="0" l16="0" g7221="0" opus="0" h264="1" h263-1998="2" t38="1" tel-event-pt="0"/>
  <accounts>
    <dynamic msr_name="msr_1" realm="sip:192.168.2.21:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password"/>
    <dynamic msr_name="msr_1" realm="sip:192.168.2.22:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password"/>
  </accounts>
  <pbyte>
    <mcc bind-addr="192.168.2.21" port="5700"/>
  </pbyte>
  <conf_dir path="/etc/ecss/ecss-media-server/conf.d"/>
  <rtp>
    <auto addr-v4=""/>
  </rtp>
</config>

На втором сервере адрес transport bind-addr и mcc bind-addr нужно указать 192.168.2.22. В секции аккаунтов задать имя MSR отличное от того, которое было задано для первого сервера, т.к. фактически настраивается отдельный второй медиасервер.

Конфигурационный файл для второго сервера должен иметь вид:

<?xml version="1.0" encoding="utf-8"?>
<config date="05:00:58 28.01.2021">
  <general log-level="3" log-rotate="yes" max-calls="8192" max-in-group="512" load-sensor="media" load-delta="10" spool-dir-size="100M" log-name="msr.log" log-path="/var/log/ecss/media-server" use-srtp="disabled" suspicious-mode="no"/>
  <transport bind-addr="192.168.2.22" port="5040" transport="udp+tcp"/>
  <media mixer-clock-rate="8000" use-vad="no" cng-level="0" jb-size="60" rtcp-timeout="0" rtp-timeout="350" udp-src-check="no" cn-multiplier="3" port-start="12000" port-range="2048" tias-in-sdp="no" thread-cnt="2" silence-threshold="-30" dtmf-flash-disable="no" video-dscp="0" other-dscp="0" dummy-video-src="/usr/share/ecss-media-server/video/dummy_video.yuv" video-enc-width="1280" video-enc-height="720" finalsilence="1000" rtcp-stat-dump="yes"/>
  <codec pcma="1" pcmu="2" ilbc="0" gsm="0" g722="3" g729="0" speex="0" l16="0" g7221="0" opus="0" h264="1" h263-1998="2" t38="1" tel-event-pt="0"/>
  <accounts>
    <dynamic msr_name="msr_2" realm="sip:192.168.2.22:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password"/>
    <dynamic msr_name="msr_2" realm="sip:192.168.2.21:5000" dtmf_mode="rfc+inband+info" auth_name="user" auth_password="password"/>
  </accounts>
  <pbyte>
    <mcc bind-addr="192.168.2.22" port="5700"/>
  </pbyte>
  <conf_dir path="/etc/ecss/ecss-media-server/conf.d"/>
  <rtp>
    <auto addr-v4=""/>
  </rtp>
</config>

В настройках ECSS-10 нужно указать адрес для приема регистраций (в целях безопасности, т.к. по умолчанию соединения принимаются на всех адресах — 0.0.0.0). Для каждого сервера — свой:

/system/media/registrar/set private core1@ecss1 listen-ip 192.168.2.21
Private parameter listen-ip set to 192.168.1.1 at node core1@ecss1.
/system/media/registrar/set private core1@ecss2 listen-ip 192.168.2.22
Private parameter listen-ip set to 192.168.1.2 at node core1@ecss2.

Далее следует задекларировать медиаресурсы каждого медиасервера на каждой ноде каждого ядра. Т.е. первый медиасервер задекларировать на обоих серверах и второй медиасервер также задекларировать на обоих серверах.

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

/system/media/resource/declare core1@ecss1 iface msr_1 bond1.2 default local true
/system/media/resource/declare core1@ecss1 iface msr_2 bond1.2 default local true
/system/media/resource/declare core1@ecss2 iface msr_1 bond1.2 default local true
/system/media/resource/declare core1@ecss2 iface msr_2 bond1.2 default local true

В результате должно появиться четыре записи ресурсов:

/system/media/resource/list active
  Active media resource selected list specific:
┌─────────────┬───────┬───────────┬───────────┬──────┬────────┬───────────┬───────────┬───────────────────┬─────────┬──────────────┬────────┬─────────┬───────┬───────────────┬────────────┬─────────┐
│    Node     │  MSR  │    MSR    │    MSR    │ MSR  │ Cc-id  │ Cc-status │ Cc-uptime │    Cc-address     │  Iface  │    Iface     │ Active │  Zone   │ Site  │    Contact    │   Status   │ Expired │
│             │       │  version  │ perf coef │ load │        │           │           │                   │  name   │     addr     │        │         │       │               │            │         │
├─────────────┼───────┼───────────┼───────────┼──────┼────────┼───────────┼───────────┼───────────────────┼─────────┼──────────────┼────────┼─────────┼───────┼───────────────┼────────────┼─────────┤
│ core1@ecss1 │ msr_1 │ 3.14.16.0 │       1.0 │    0 │ 22abcd │ connected │ 07:16:24  │ 192.168.2.21:5700 │ bond1.2 │ 192.168.2.21 │ true   │ default │ local │ bond1.2@msr_1 │ registered │      50 │
│             │ msr_2 │ 3.14.16.0 │       1.0 │    0 │ c5b9d8 │ connected │ 07:16:26  │ 192.168.2.22:5700 │ bond1.2 │ 192.168.2.22 │ true   │ default │ local │ bond1.2@msr_2 │ registered │      48 │
│ core1@ecss2 │ msr_1 │ 3.14.16.0 │       1.0 │    0 │ 22abcd │ connected │ 07:18:57  │ 192.168.2.21:5700 │ bond1.2 │ 192.168.2.21 │ true   │ default │ local │ bond1.2@msr_1 │ registered │      76 │
│             │ msr_2 │ 3.14.16.0 │       1.0 │    0 │ c5b9d8 │ connected │ 07:18:18  │ 192.168.2.22:5700 │ bond1.2 │ 192.168.2.22 │ true   │ default │ local │ bond1.2@msr_2 │ registered │      57 │
└─────────────┴───────┴───────────┴───────────┴──────┴────────┴───────────┴───────────┴───────────────────┴─────────┴──────────────┴────────┴─────────┴───────┴───────────────┴────────────┴─────────┘

Механизм перепарковки вызовов при остановке/перезапуске медиасервера

При остановке или перезапуске медиасервера, он предварительно завершает все активные sip-сессии до ядер, отправляя BYE c полем Reason со значением SIP;cause=480;text="System Shutdown".
Каждое ядро, принимая данный BYE, понимает, что медиасервер остановили/перезапустили и инициирует процедуру перепарковки данного вызова на другой медиасервер.

Пример сообщения BYE:

BYE sip:core@192.168.23.3:5000 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5040;rport;branch=z9hG4bKPjtPrQHcWDEo-bflsWmwrMTCj.3PnfioVH
Max-Forwards: 70
From: <sip:enp3s0@127.0.0.1>;tag=xxUS3tNZtP3VUn4z1Eld9Y.tVh-vg57B
To: <sip:core@ecss10>;tag=asRx2P
Call-ID: g2gEZAALdGVzdC5kb21haW5tAAAAEGYwNzkxM2I4NmMyNzZmMjFtAAAAEGYwNzkxM2JhMmM5ODhjMjhhAQ==
CSeq: 23023 BYE
User-Agent: Eltex media-server 3.10.0.5
Reason: SIP;cause=480;text="System Shutdown" 
Content-Length:  0

Система с несколькими интерфейсами

Условия

Система настроена для работы по примеру Системы с одним сервером.

Необходимо добавить интерфейс bond1.3 для обслуживания медиасервером.

Настройки

Декларируем медиаресурсы для нового интерфейса:

/system/media/resource/declare core1@ecss1 by_iface msr_1 bond1.3 default local true

Система с отдельным медиасервером для селекторной связи на одном хосте

Преимущества

Все вызовы на селектор/с селектора будут парковаться на отдельный медиасервер (медиасервер селекторных совещаний). Если вызов нельзя запарковать на медиасервер, то он будет отклонен.

Условия

Система настроена для работы по примеру Системы с одним сервером.

Настройки

Потребуется сайты для абонентов и для медиасерверов.

Для абонентов требуются сайты:

1. local для абонентов. По умолчанию, все абонентов имеют site равный local;
2. tc для селекторной связи.

Для медиа-серверов требуются site:

1. video — для медиасервера с поддержкой видео;
2. without-video — для медиасервера без поддержки видео.

Декларируем перечисленные выше сайты через расширенный web или Cocon:

system/media/site/declare <site>

, в итоге имеет матрицу сайтов:

/system/media/site/matrix       
┌───────────────┬───┬───┬────┬────┬───┐
│   site        │ # │ 1 │ 2  │ 3  │ 4 │
├───────────────┼───┼───┼────┼────┼───┤
│ local         │ 1 │ 0 │    │    │   │
│ tc            │ 2 │   │  0 │    │   │
│ video         │ 3 │   │    │  0 │   │
│ without-video │ 4 │   │    │    │ 0 │
└───────────────┴───┴───┴────┴────┴───┘

The site of row is correspond to site of iface(domain/<domain>/iface).
The site of column is correspond to site of contact(system/media/resource/list).

Legend:
  r - the distance is present only when there is another subscriber with a distance not equal to the value r(relation) to a given msr.
  empty distance - infinity distance between sites.

После этого настраиваем расстояния между сайтами расширенный web или Cocon:

system/media/site/distance <from site> <to site> <distance>

, чтобы матрица расстояний выглядела следующим образом:

/system/media/site/matrix 
┌───────────────┬───┬───┬────┬────┬───┐
│   site        │ # │ 1 │ 2  │ 3  │ 4 │
├───────────────┼───┼───┼────┼────┼───┤
│ local         │ 1 │ 0 │    │  5 │ 6 │
│ tc            │ 2 │   │  0 │ 10 │ 3 │
│ video         │ 3 │ 5 │ 10 │  0 │   │
│ without-video │ 4 │ 6 │  3 │    │ 0 │
└───────────────┴───┴───┴────┴────┴───┘

The site of row is correspond to site of iface(domain/<domain>/iface).
The site of column is correspond to site of contact(system/media/resource/list).

Legend:
  r - the distance is present only when there is another subscriber with a distance not equal to the value r(relation) to a given msr.
  empty distance - infinity distance between sites.

Выставляем site в tc для системного интерфейса system:teleconference:

/domain/test.domain/iface/user-set * * system:teleconference site tc
Property 'site' successfully changed to 'tc' for interfaces:
system:teleconference

Настраиваем конфигурационный файл для медиасервера селекторной связи:

/etc/ecss/ecss-media-server/config-without-video.xml

Выставляем параметры port-start, port-range и port в секции mcc, таким образом, чтобы они не пересекались с параметрами уже запущенных медиасерверов.

Включаем медиасервер селекторных совещаний:

sudo systemctl enable ecss-media-server@without-video

Запускаем медиасервер селекторных совещаний:

sudo systemctl start ecss-media-server@without-video

Декларируем контакты медиа-сервера с видео с site равным video, пример:

/system/media/resource/declare * iface paul enp0s8 default video true          
  Declared media resources
┌─────────────┬─────────────┬────────┬─────────┬───────┐
│    Node     │   Contact   │ Active │   Zone  │  Site │
├─────────────┼─────────────┼────────┼─────────┼───────┤
│ core1@IBM   │ enp0s8@paul │ true   │ default │ video │
│ core2@IBM   │ enp0s8@paul │ true   │ default │ video │
│ core1@ecss1 │ enp0s8@paul │ true   │ default │ video │
│ core1@ecss2 │ enp0s8@paul │ true   │ default │ video │
│ core1@PAUL  │ enp0s8@paul │ true   │ default │ video │
│ core2@PAUL  │ enp0s8@paul │ true   │ default │ video │
└─────────────┴─────────────┴────────┴─────────┴───────┘

Декларируем контакты медиасервера без видео с site равным without-video, пример:

/system/media/resource/declare * iface paul.without-video enp0s8 default without-video true  
  Declared media resources
┌─────────────┬───────────────────────────┬────────┬─────────┬───────────────┐
│    Node     │          Contact          │ Active │   Zone  │      Site     │
├─────────────┼───────────────────────────┼────────┼─────────┼───────────────┤
│ core1@IBM   │ enp0s8@paul.without-video │ true   │ default │ without-video │
│ core2@IBM   │ enp0s8@paul.without-video │ true   │ default │ without-video │
│ core1@ecss1 │ enp0s8@paul.without-video │ true   │ default │ without-video │
│ core1@ecss2 │ enp0s8@paul.without-video │ true   │ default │ without-video │
│ core1@PAUL  │ enp0s8@paul.without-video │ true   │ default │ without-video │
│ core2@PAUL  │ enp0s8@paul.without-video │ true   │ default │ without-video │
└─────────────┴───────────────────────────┴────────┴─────────┴───────────────┘

Если контакты уже были задекларированы, для контактов медиасервера с видео выставляем site в video, пример:

/system/media/resource/set * enp0s8@paul site video          
  Media resource:
┌─────────────┬─────────────┬──────────┬───────┐
│    Node     │   Contact   │ Property │ Value │
├─────────────┼─────────────┼──────────┼───────┤
│ core2@PAUL  │ enp0s8@paul │ site     │ video │
│ core1@PAUL  │ enp0s8@paul │ site     │ video │
│ core1@ecss2 │ enp0s8@paul │ site     │ video │
│ core1@ecss1 │ enp0s8@paul │ site     │ video │
│ core2@IBM   │ enp0s8@paul │ site     │ video │
│ core1@IBM   │ enp0s8@paul │ site     │ video │
└─────────────┴─────────────┴──────────┴───────┘

а для контактов медиа-сервера без видео выставляем  site  в without-video, пример:

/system/media/resource/set * enp0s8@paul.without-video site without-video  
  Media resource:
┌─────────────┬───────────────────────────┬──────────┬───────────────┐
│    Node     │          Contact          │ Property │     Value     │
├─────────────┼───────────────────────────┼──────────┼───────────────┤
│ core2@PAUL  │ enp0s8@paul.without-video │ site     │ without-video │
│ core1@PAUL  │ enp0s8@paul.without-video │ site     │ without-video │
│ core1@ecss2 │ enp0s8@paul.without-video │ site     │ without-video │
│ core1@ecss1 │ enp0s8@paul.without-video │ site     │ without-video │
│ core2@IBM   │ enp0s8@paul.without-video │ site     │ without-video │
│ core1@IBM   │ enp0s8@paul.without-video │ site     │ without-video │
└─────────────┴───────────────────────────┴──────────┴───────────────┘

Система с использованием site (территориального тяготения)

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

Преимущества

• не нужно поднимать интерфейс медиасервера для zone without-video;
• если упадет медиасервер с site without-video, то вызовы перепаркуются на доступный медиасервер (до которого есть расстояние в матрице расстояний между site). В случае zone, вызовы не будут перепаркованы, а будут зарелижены, т.к. больше не будет медиасервера, который бы одновременно находился в zone default и zone without-video.

Настройка

В примере рассматривается система с использованием 3 MSR. Количество MSR можно увеличить в зависимости от требований к системе.

Для абонентов требуются site:

• local для абонентов. По умолчанию, все абонентов имеют site равный local;
• tc для селекторной связи.
• Для медиасерверов требуются site:
• video — для медиасервера с поддержкой видео;
• without-video — для медиасервера без поддержки видео.

Декларируем перечисленные выше site командой:

system/media/site/declare <site>

Ожидаемая матрица после декларации сайтов:

/system/media/site/matrix       
┌───────────────┬───┬───┬────┬────┬───┐
│   site        │ # │ 1 │ 2  │ 3  │ 4 │
├───────────────┼───┼───┼────┼────┼───┤
│ local         │ 1 │ 0 │    │    │   │
│ tc            │ 2 │   │  0 │    │   │
│ video         │ 3 │   │    │  0 │   │
│ without-video │ 4 │   │    │    │ 0 │
└───────────────┴───┴───┴────┴────┴───┘

The site of row is correspond to site of iface(domain/<domain>/iface).
The site of column is correspond to site of contact(system/media/resource/list).

Legend:
  r - the distance is present only when there is another subscriber with a distance not equal to the value r(relation) to a given msr.
  empty distance - infinity distance between sites.

После этого настраиваем расстояния между сайтами командой:

system/media/site/distance <from site> <to site> <distance>

Ожидаемый результат настройки сайтов для данного примера:

/system/media/site/matrix 
┌───────────────┬───┬───┬────┬────┬───┐
│   site        │ # │ 1 │ 2  │ 3  │ 4 │
├───────────────┼───┼───┼────┼────┼───┤
│ local         │ 1 │ 0 │    │  5 │ 6 │
│ tc            │ 2 │   │  0 │ 10 │ 3 │
│ video         │ 3 │ 5 │ 10 │  0 │   │
│ without-video │ 4 │ 6 │  3 │    │ 0 │
└───────────────┴───┴───┴────┴────┴───┘

The site of row is correspond to site of iface(domain/<domain>/iface).
The site of column is correspond to site of contact(system/media/resource/list).

Legend:
  r - the distance is present only when there is another subscriber with a distance not equal to the value r(relation) to a given msr.
  empty distance - infinity distance between sites.

Задание таких расстояний преследовало следующие поведения:

1. Вызовы с абонента на абонента должны парковаться на медиасервер, поддерживающий видео: задаем расстояние между абонентом с site равным local (default-значение для абонента) и медиасервером с поддержкой видео с site, равным video в 5;
2. В случае, если медиасервер с поддержкой видео стал недоступен, вызов с абонент на абонента должен парковаться/перепарковываться на любой другой доступный медиа-сервер. В данном случае, это медиа-сервис без поддержки видео => задаем расстояние между абонентом с site равным local и медиа-сервером без поддержкой видео с site равным without-video в 6. Данное значение должно быть больше расстояния между site локального абонента и site медиа-сервера с поддержкой видео. Если его выставить в 5, то между этими двумя медиасерверами, медиасервер будет выбран равновероятно (в зависимости от его загруженности и коэффициента производительности);
3. Вызов с абонента на конференцию должен парковаться на медиасервер без поддержки видео: задаем расстояние между телеконференцией с site, равным tc и медиа-сервером без поддержки видео с site, равным without-video в 3. Данное значение должно быть наименьшим среди всех остальных расстояний до других медиасерверов, т.к. выбирается медиасервер до которого расстояние наименьшее.
4. В случае, если медиасервер без поддержки видео стал недоступен, вызов с абонента на конференцию должен парковаться/перепарковываться на любой другой доступный медиасервер. В данном случае это медиа-сервис с поддержкой видео. Выставляем расстояние между site конференцию и site медиасервера в 10.

Выставляем site в tc для системного интерфейса system:teleconference:

/domain/test.domain/iface/user-set * * system:teleconference site tc
Property 'site' successfully changed to 'tc' for interfaces:
system:teleconference

Декларируем контакты медиасервера с видео с site равным video:

/system/media/resource/declare * iface paul enp0s8 default video true          
  Declared media resources
┌─────────────┬─────────────┬────────┬─────────┬───────┐
│    Node     │   Contact   │ Active │   Zone  │  Site │
├─────────────┼─────────────┼────────┼─────────┼───────┤
│ core1@IBM   │ enp0s8@paul │ true   │ default │ video │
│ core2@IBM   │ enp0s8@paul │ true   │ default │ video │
│ core1@ecss1 │ enp0s8@paul │ true   │ default │ video │
│ core1@ecss2 │ enp0s8@paul │ true   │ default │ video │
│ core1@PAUL  │ enp0s8@paul │ true   │ default │ video │
│ core2@PAUL  │ enp0s8@paul │ true   │ default │ video │
└─────────────┴─────────────┴────────┴─────────┴───────┘

Декларируем контакты медиасервера без видео с site, равным without-video:

/system/media/resource/declare * iface paul.without-video enp0s8 default without-video true  
  Declared media resources
┌─────────────┬───────────────────────────┬────────┬─────────┬───────────────┐
│    Node     │          Contact          │ Active │   Zone  │      Site     │
├─────────────┼───────────────────────────┼────────┼─────────┼───────────────┤
│ core1@IBM   │ enp0s8@paul.without-video │ true   │ default │ without-video │
│ core2@IBM   │ enp0s8@paul.without-video │ true   │ default │ without-video │
│ core1@ecss1 │ enp0s8@paul.without-video │ true   │ default │ without-video │
│ core1@ecss2 │ enp0s8@paul.without-video │ true   │ default │ without-video │
│ core1@PAUL  │ enp0s8@paul.without-video │ true   │ default │ without-video │
│ core2@PAUL  │ enp0s8@paul.without-video │ true   │ default │ without-video │
└─────────────┴───────────────────────────┴────────┴─────────┴───────────────┘

Если контакты уже были задекларированы, для контактов медиасервера с видео выставляем site в video:

/system/media/resource/set * enp0s8@paul site video          
  Media resource:
┌─────────────┬─────────────┬──────────┬───────┐
│    Node     │   Contact   │ Property │ Value │
├─────────────┼─────────────┼──────────┼───────┤
│ core2@PAUL  │ enp0s8@paul │ site     │ video │
│ core1@PAUL  │ enp0s8@paul │ site     │ video │
│ core1@ecss2 │ enp0s8@paul │ site     │ video │
│ core1@ecss1 │ enp0s8@paul │ site     │ video │
│ core2@IBM   │ enp0s8@paul │ site     │ video │
│ core1@IBM   │ enp0s8@paul │ site     │ video │
└─────────────┴─────────────┴──────────┴───────┘

Для контактов медиасервера без видео выставляем site в without-video:

/system/media/resource/set * enp0s8@paul.without-video site without-video  
  Media resource:
┌─────────────┬───────────────────────────┬──────────┬───────────────┐
│    Node     │          Contact          │ Property │     Value     │
├─────────────┼───────────────────────────┼──────────┼───────────────┤
│ core2@PAUL  │ enp0s8@paul.without-video │ site     │ without-video │
│ core1@PAUL  │ enp0s8@paul.without-video │ site     │ without-video │
│ core1@ecss2 │ enp0s8@paul.without-video │ site     │ without-video │
│ core1@ecss1 │ enp0s8@paul.without-video │ site     │ without-video │
│ core2@IBM   │ enp0s8@paul.without-video │ site     │ without-video │
│ core1@IBM   │ enp0s8@paul.without-video │ site     │ without-video │
└─────────────┴───────────────────────────┴──────────┴───────────────┘

Настройка выделенного MSR для группы абонентов

Периодически на системе бывает так, что определенная группа абонентов Softswitch территориально удалена от сервером ECSS-10, и/или ограничена по ширине канала связи (выделенная локация). В этом случае с целью оптимизации трафика для разговора абонентов такой группы между собой есть смысл парковать их медиа на отдельно стоящий MSR, который будет расположен на той же локации что и абоненты. При этом, если абонент данной локации разговаривает с абонентом "центра", то использоваться должен основной MSR. В данном разделе описывается пошаговая инструкция по настройке данной схемы.

Пример:

Есть Softswitch, стоящий в Москве, им пользуются vip-клиенты, локальные пользователи, а также существует возможность собирать телеконференции. Для каждого из этих типов пользователей имеется отдельный MSR. По умолчанию в системе создан site local, в котором по умолчанию создаются все абоненты ECSS-10.

Создание site-ов

Нужно создать site для абонента VIP и TC.

По умолчанию список site следующий:

/system/media/site/list         
List of all sites:
 local

Создаем site для абонента VIP:

/system/media/site/declare vip     
Site: vip
 Created successfully.

Создаем site для абонентов TC:

/system/media/site/declare tc    
Site: tc
 Created successfully.

После изменений список site следующий:

/system/media/site/list          
List of all sites:
 local
 vip
 tc

Настройка матрицы связности между site

После создания site матрица связности между site будет следующей:

/system/media/site/matrix       
┌───────────┬───┬───┬───┬───┐
│ site      │ # │ 1 │ 2 │ 3 │ 
├───────────┼───┼───┼───┼───┤
│ vip       │ 1 │ 0 │   │   │
│ local     │ 2 │   │ 0 │   │
│ tc        │ 3 │   │   │ 0 │
└───────────┴───┴───┴───┴───┘

The site of row is correspond to site of iface(domain/<domain>/iface).
The site of column is correspond to site of contact(system/media/resource/list).

Legend:
  r - the distance is present only when there is another subscriber with a distance not equal to the value r(relation) to a given msr.
  empty distance - infinity distance between sites.

К MSR1 должен быть привязан site vip, к MSR2 local, к MSR3 tc.

Выставляем расстояние между  абонентами VIP и медиасервером MSR.1, который также использует сайт VIP:

/system/media/site/distance vip vip 10
Distance between vip and vip changed to: 10.

Выставляем расстояние между  абонентами VIP и медиасервером MSR.2, который использует сайт LOCAL:

/system/media/site/distance vip local 20
Distance between vip and local changed to: 20.

Выставляем расстояние между абонентами VIP и медиасервером MSR.3, который использует сайт TC:

/system/media/site/distance vip tc 50
Distance between vip and tc changed to: 50.

Выставляем расстояние между абонентами LOCAL и медиасервером MSR.1, который использует сайт VIP:

/system/media/site/distance local vip r
Distance between local and vip changed to: r.

Выставляем расстояние между абонентами LOCAL и медиасервером MSR.2, который использует сайт LOCAL:

/system/media/site/distance local local 10
Distance between local and local changed to: 10.

Выставляем расстояние между абонентами LOCAL и медиасервером MSR.3, который использует сайт ТС:

/system/media/site/distance local tc 50
Distance between local and tc changed to: 50.

Выставляем расстояние между TC и медиасервером MSR.3, который использует сайт ТС:

/system/media/site/distance tc tc 0
Distance between local and tc changed to: 0.

После изменений матрица связности следующая:

/system/media/site/matrix                                 
┌───────┬───┬───┬────┬────┐
│ site  │ # │ 1 │ 2  │ 3  │
├───────┼───┼───┼────┼────┤
│ vip   │ 1 │ 0 │ 20 │ 50 │
│ local │ 2 │ r │ 10 │ 50 │
│ tc    │ 3 │   │    │  0 │
└───────┴───┴───┴────┴────┘

Декларация ресурсом медиа-серверов

Пусть на ядре зарегистрированы 3 медиасервера: MSR.1, MSR.2, MSR.3.

/system/media/resource/list all
  All media resource selected list specific:
┌─────────────┬───────┬─────────────┬───────────┬──────┬────────┬───────────┬───────────┬──────────────────────┬─────────────┬─────────────────┬────────┬─────────┬───────┬───────────────────┬──────────────┬─────────┐
│    Node     │  MSR  │   MSR       │    MSR    │ MSR  │ Cc-id  │ Cc-status │ Cc-uptime │      Cc-address      │    Iface    │      Iface      │ Active │  Zone   │ Site  │      Contact      │    Status    │ Expired │
│             │       │ version     │ perf coef │ load │        │           │           │                      │    name     │      addr       │        │         │       │                   │              │         │
├─────────────┼───────┼─────────────┼───────────┼──────┼────────┼───────────┼───────────┼──────────────────────┼─────────────┼─────────────────┼────────┼─────────┼───────┼───────────────────┼──────────────┼─────────┤
│ core1@ecss1 │ MSR.1 │ 3.14.15.243 │       1.0 │    0 │ 0b131b │ connected │ 01:28:59  │ 127.0.0.1:5700       │ lo          │ 127.0.0.1       │ false  │         │       │ lo@MSR.1          │ registered   │     119 │
│             │       │             │           │      │        │           │           │                      │ eno4        │ 192.168.116.179 │ false  │         │       │ eno4@MSR.1        │ registered   │     119 │
│             │ MSR.2 │ 3.14.15.243 │       1.0 │    0 │ 7a7740 │ connected │ 01:26:08  │ 10.24.40.53:5700     │ enp2s0      │ 192.168.116.181 │ false  │         │       │ enp2s0@MSR.2      │ registered   │     170 │
│             │       │             │           │      │        │           │           │                      │ lo          │ 127.0.0.1       │ false  │         │       │ lo@MSR.2          │ registered   │     170 │
│             │ MSR.3 │ 3.14.15.243 │       1.0 │    0 │ f01fb6 │ connected │ 00:20:06  │ 192.168.116.131:5700 │ bond1       │ 192.168.116.131 │ false  │         │       │ bond1@MSR.3       │ registered   │     173 │ 
│             │       │             │           │      │        │           │           │                      │ lo          │ 127.0.0.1       │ false  │         │       │ lo@MSR.3          │ registered   │     174 │
└─────────────┴───────┴─────────────┴───────────┴──────┴────────┴───────────┴───────────┴──────────────────────┴─────────────┴─────────────────┴────────┴─────────┴───────┴───────────────────┴──────────────┴─────────┘

Декларируем ресурс медиасервера MSR.1 c site vip:

/system/media/resource/declare * iface MSR.1 eno4 default vip true       
  Declared media resources
┌─────────────┬────────────┬────────┬─────────┬─────────┐
│    Node     │  Contact   │ Active │   Zone  │   Site  │
├─────────────┼────────────┼────────┼─────────┼─────────┤
│ core1@IBM   │ eno4@MSR.1 │ true   │ default │ vip     │
│ core2@IBM   │ eno4@MSR.1 │ true   │ default │ vip     │
└─────────────┴────────────┴────────┴─────────┴─────────┘

Декларируем ресурс медиасервера MSR.2 c site local:

/system/media/resource/declare * iface MSR.2 enp2s0 default local true       
  Declared media resources
┌─────────────┬──────────────┬────────┬─────────┬─────────┐
│    Node     │    Contact   │ Active │   Zone  │   Site  │
├─────────────┼──────────────┼────────┼─────────┼─────────┤
│ core1@IBM   │ enp2s0@MSR.2 │ true   │ default │ local   │
│ core2@IBM   │ enp2s0@MSR.2 │ true   │ default │ local   │
└─────────────┴──────────────┴────────┴─────────┴─────────┘

Декларируем ресурс медиасервера MSR.3 c site tc:

/system/media/resource/declare * iface MSR.3 bond1 default tc true       
  Declared media resources
┌─────────────┬──────────────┬────────┬─────────┬─────────┐
│    Node     │    Contact   │ Active │   Zone  │   Site  │
├─────────────┼──────────────┼────────┼─────────┼─────────┤
│ core1@IBM   │ bond1@MSR.3  │ true   │ default │ tc      │
│ core2@IBM   │ bond1@MSR.3  │ true   │ default │ tc      │
└─────────────┴──────────────┴────────┴─────────┴─────────┘

После изменений список ресурсов следующий:

/system/media/resource/list all
  All media resource selected list specific:
┌─────────────┬───────┬─────────────┬───────────┬──────┬────────┬───────────┬───────────┬──────────────────────┬─────────────┬─────────────────┬────────┬─────────┬───────┬───────────────────┬──────────────┬─────────┐
│    Node     │  MSR  │   MSR       │    MSR    │ MSR  │ Cc-id  │ Cc-status │ Cc-uptime │      Cc-address      │    Iface    │      Iface      │ Active │  Zone   │ Site  │      Contact      │    Status    │ Expired │
│             │       │ version     │ perf coef │ load │        │           │           │                      │    name     │      addr       │        │         │       │                   │              │         │
├─────────────┼───────┼─────────────┼───────────┼──────┼────────┼───────────┼───────────┼──────────────────────┼─────────────┼─────────────────┼────────┼─────────┼───────┼───────────────────┼──────────────┼─────────┤
│ core1@ecss1 │ MSR.1 │ 3.14.15.243 │       1.0 │    0 │ 0b131b │ connected │ 01:28:59  │ 127.0.0.1:5700       │ lo          │ 127.0.0.1       │ false  │         │       │ lo@MSR.1          │ registered   │     119 │
│             │       │             │           │      │        │           │           │                      │ eno4        │ 192.168.116.179 │ true   │default  │vip    │ eno4@MSR.1        │ registered   │     119 │
│             │ MSR.2 │ 3.14.15.243 │       1.0 │    0 │ 7a7740 │ connected │ 01:26:08  │ 10.24.40.53:5700     │ enp2s0      │ 192.168.116.181 │ true   │default  │local  │ enp2s0@MSR.2      │ registered   │     170 │
│             │       │             │           │      │        │           │           │                      │ lo          │ 127.0.0.1       │ false  │         │       │ lo@MSR.2          │ registered   │     170 │
│             │ MSR.3 │ 3.14.15.243 │       1.0 │    0 │ f01fb6 │ connected │ 00:20:06  │ 192.168.116.131:5700 │ bond1       │ 192.168.116.131 │ true   │default  │tc     │ bond1@MSR.3       │ registered   │     173 │ 
│             │       │             │           │      │        │           │           │                      │ lo          │ 127.0.0.1       │ false  │         │       │ lo@MSR.3          │ registered   │     174 │
└─────────────┴───────┴─────────────┴───────────┴──────┴────────┴───────────┴───────────┴──────────────────────┴─────────────┴─────────────────┴────────┴─────────┴───────┴───────────────────┴──────────────┴─────────┘

Выставление site-ов на абонентах

По умолчанию на абоненте site выставлен в local. Для того, чтобы абонента сделать абонентом VIP, нужно на абоненте выставить site в vip:

/domain/test.domain/iface/user-set * * 103@test.domain site vip       
Property 'site' successfully changed to 'vip' for interfaces:
103@test.domain

Принцип распределения вызов

При выставлении на интерфейсе system:teleconference сайта tc, все конференции будут собираться через MSR.3. В случае его падения конференции собираться не будут.
Звонки между VIP абонентами будут проходить через MSR.1, в случае его падения через MSR.2, если же и MSR.2 будет иметь неисправности, то вызовы пойдут через MSR.3.
Локальные абоненты будут задействовать MSR.2, в случае его падения MSR.3.
Звонки между VIP и локальными абонентами будут осуществляться через MSR.1 и MSR.2.