Описание

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

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

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

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

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

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

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

ECSS-Archieves > 3.14.0 Конфигурирование распределенного медиасервера > Схема1_.jpg

Рисунок 1

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

ECSS-Archieves > 3.14.0 Конфигурирование распределенного медиасервера > Схема2_.jpg

Рисунок 2

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

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

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

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

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

Для каждого сетевого интерфейса формируется свой отдельный SIP UA.
Один из сетевых интерфейсов отмечается как служебный (на этапе конфигурирования). Через него передается SIP трафик. UA для этого интерфейса единственный у которого связка сигнализации и медиа делается на одном и том же сетевом интерфейсе. UA остальных интерфейсов используют транспорт служебного интерфейса для SIP, а привязка приемника/передатчика медиатрафика осуществляется к анонсируемого SIP UA сетевому интерфейсу.
Информация об анонсируемом сетевом интерфейсе передается в 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.
Cc-status, Cc-id & Cc-address(Control channel status, Control channel id & Control channel address) формируются только для служебного интерфейса;
URI UA формируется по следующему формату: {interface-name};{msr-contact-id}@{MSR-name};
1. interface-name - имя анонсируемого интерфейса;
2. msr-contact-id - идентификатор dynamic контакта на MSR;
3. MSR-name - имz медиасервера (имя хоста или указанное при инсталляции имя).
IFace(анонсируемый интерфейс) имеет вид: interface-name(MEDIA-IP-Address), где:
1. interface-name - имя анонсируемого интерфейса;
2. MEDIA-IP-Address - IP-адрес анонсируемого интерфейса к которому привязывается медиаресурс.

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

Для регистрации медиасерверов выделяется отдельный служебный регистратор, который расположен на ядре системы (Core). Регистратор работает в служебном VLAN-X (отдельный порт, выделенный интерфейс).
Сигнальный трафик от медиасерверов обрабатывается SIP-сервером, который встроен с ядром (Core) и обрабатывается в служебном VLAN-X.
Функционал регистратора:
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) медиасервера, либо при принудительном отказе в регистрации.
Функционал SIP-сервера:
1. установка SIP-сессий с выбранным аккаунтом;
2. поддерка установленных SIP-сессий (механизм reINVITE);
3. нотификация о фактах развала SIP-сессии по инициативе MSR (либо при потере связи с MSR).
Функционал управления контрольными каналами:
1. установка и поддержка контрольных каналов по одному до каждого медиасервера
2. сворачивание контрольного канала в случае отказа в регистрации медиасревера
3. передача mediactrl-сообщений в нужный контрольный канал, который выбирается по идентификатору канала (равен служебному SIP URI медиасервера).

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

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

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

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

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

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

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

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

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

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

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

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

admin@[restfs1@IBM]:/$ 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.

[exec at: 02.08.2017 12:19:55, exec time: 19ms, nodes: core2@IBM]

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

Контакты, полученные на предыдущем шаге, сортируем с удалением дубликатов по имени msr (поле msr_name). Получаем контакты с уникальными msr-ами. Контакты содержат информацию о загруженности msr-а и коэффициенте производительности msr-а;
На основе контактов, полученных на предыдущем шаге, строится интервальная таблица загруженности 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 регистрируют контакты со следующими параметрами:

name	zone	site	msr_id
msr1_eth0	rtk	r_kalininsky	1
msr1_eth1	mts	r_kalininsky	1
msr2_eth0	rtk	r_sovetsky	2
msr2_eth1	mts	r_sovetsky	2
msr3_eth0	rtk	r_kirovsky	3
msr3_eth1	mts	r_kirovsky	3

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

Site-name	d	1	2	3	4	5	6
r_kalininsky	1	0
r_sovetsky	2		0
r_kirovsky	3			0
okrujnaya	4	1	3	2	0
molodeji	5	3	1	2		0
titova	6	2	2	1			0

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

UA	zone	site
ua1	rtk	okrujnaya
ua2	mts	molodeji

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

name	zone	site	msr_id
msr1_eth0	rtk	r_kalininsky	1
msr2_eth0	rtk	r_sovetsky	2
msr3_eth0	rtk	r_kirovsky	3

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

distance	name	zone	site	msr_id
1	msr1_eth0	rtk	r_kalininsky	1
2	msr3_eth0	rtk	r_kirovsky	3
3	msr2_eth0	rtk	r_sovetsky	2

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

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

name	zone	site	msr_id
msr1_eth1	mts	r_kalininsky	1
msr2_eth1	mts	r_sovetsky	2
msr3_eth1	mts	r_kirovsky	3

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

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

name	zone	site	msr_id
msr1_eth1	mts	r_kalininsky	1

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

distance	name	zone	site	msr_id
1	msr1_eth1	mts	r_kalininsky	1

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

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

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

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

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

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

Примеры:

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

system/media/msr/set msr_1 performance_coefficient 2
 msr   msr_1
 set   performance_coefficient
 from  1.0
 to    2

[exec at: 21.07.2019 21:37:08, exec time: 102ms, nodes: core1@ecss1]

Просмотр:

admin@mycelium1@ecss1:/$ system/media/msr/list                                            
 Auto declared media server list specific:
┌───────┬─────────────┐
│ Name  │ Performance │
│       │ coefficient │
├───────┼─────────────┤
│ msr_1 │         2.0 │
│ msr_2 │         1.0 │
└───────┴─────────────┘

[exec at: 21.07.2019 21:37:12, exec time: 11ms, nodes: core1@ecss1]

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

admin@mycelium1@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_1 │ 3.14.0.156 │       2.0 │    0 │ 22abcd │ connected │ 1 12:01:16 │ 192.168.2.21:5700 │ bond1.2 │ 192.168.2.21 │ true   │ default │ local │ bond1.2@msr_1 │ registered │      58 │
│             │ msr_2 │ 3.14.0.156 │       1.0 │    0 │ c5b9d8 │ connected │ 12:01:10   │ 192.168.2.22:5700 │ bond1.2 │ 192.168.2.22 │ true   │ default │ local │ bond1.2@msr_2 │ registered │      57 │
└─────────────┴───────┴────────────┴───────────┴──────┴────────┴───────────┴────────────┴───────────────────┴─────────┴──────────────┴────────┴─────────┴───────┴───────────────┴────────────┴─────────┘

[exec at: 21.07.2019 21:51:27, exec time: 13ms, nodes: core1@ecss1]

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

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