CommuniGate Pro
Версия 6.2
Сигнализация
 
 
Cигналы

Сигналы в Реальном Времени

Одной из основных функций Сервера CommuniGate Pro является поддержка коммуникаций в реальном времени. Играя роль Сервера Сигналов, Сервер получает Сигналы реального времени (Запросы) из различных источников (модули SIP и XMPP, внутренние сессии, "плечи звонков", внутренние компоненты ядра и т.д.)
Сервер CommuniGate Pro либо обрабатывает (терминирует) эти Запросы самостоятельно, либо доставляет их удалённым сторонам (через протоколы SIP или XMPP), либо направляет их во внутренние сессии и в "плечи звонков".

Для каждого Запроса, модуль Signal дополнительно может генерировать промежуточные Ответы (такие как "Trying" или "Ringing") и один завершающий Ответ.

Адреса Записей (AOR)

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

Каждый пользователь имеет уникальный "идентификатор XMPP" или "идентификатор SIP", называемый также AOR (Address of Record, Адрес Записи).

Для несессионных протоколов, таких, как SIP, Сервер регистрирует пользователей, запоминая их "SIP идентификаторы" и используемые ими сетевые (IP) адреса.

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

Регистрации позволяют SIP пользователям взаимодействовать друг с другом не зная сетевых адресов, используя только "SIP идентификаторы" (AOR).

AOR имеют тот же вид, что и адреса электронной почты: username@domainName. AOR пользователя CommuniGate Pro является его полное имя Пользователя, и таким образом, SIP AOR в точности совпадает с адресом электронной почты.

CommuniGate Pro использует компонент Маршрутизатор для всех операций реального времени, так что Псевдонимы, Переадресаторы и других механизмы Маршрутизации также будут работать и для Коммуникаций Реального Времени.


Сигналы

Сигнал является базовой Задачей Реального времени. Один из участников коммуникаций Реального Времени отправляет Сигналы другому участнику для начала, изменения или прекращения коммуникационного диалога, изменения статуса и т.п.

Отправляющая сторона формирует объект с Запросом и посылает его в модуль Signal сервера CommuniGate Pro. Модуль Signal обрабатывает Запрос, отправляет, если требуется, Запросы другим участникам и возвращает объект с Ответом отправляющей стороне.

Многие модули и компоненты CommuniGate Pro могут использовать Сигналы:


Обработка Запросов

Когда модуль Signal получает Запрос, он вычисляет для него идентификатор ресурса URI. Он берет URI Запроса (или первый имеющийся Route URI из набора Route Запроса) и использует компонент Маршрутизатор для определения адреса назначения Запроса. Далее существует несколько вариантов развития событий:

Следующая диаграмма иллюстрирует схему обработки Сигналов в Сервере CommuniGate Pro:

Схема Сигналов

Автоматическая Обработка (Правила)

После того, как адрес был обработан при помощи Маршрутизатора, но до того, как он был ретранслирован локальному или удалённому участнику, применяются Общесерверные и Общекластерные Правила Автоматической Обработки Сигналов.

Правила управляют ходом обработки запроса: они могут перенаправить его на другой адрес или отвергнуть Запрос.

С помощью Автоматических Правил обрабатываются только Запросы, инициирующие Диалог.


Ответвление

Модуль Signal обслуживает наборы AOR (Адресов Записи) и Contact для каждого обрабатываемого Запроса. Модуль начинает процесс Ответвления, обрабатывая адреса из набора AOR.

При получении во время обработки любого AOR ответа типа 2xx, обработка останавливается. Если Запрос имел тип INIVTE, то все невыполненные Запросы, ретранслированные на другие AOR, отменяются.

После обработки всех AOR, модуль возвращает "лучший" результат обработки источнику Запроса.

Если AOR, подлежащий обработке, Направляется на нелокальный адрес, то этот адрес помещается в набор Contact.

Если AOR, подлежащий обработке, Направляется на локальную Группу, то все участники группы добавляются в набор AOR.

Если AOR, подлежащий обработке, Направляется на локального Пользователя, то все активные Регистрации Пользователя (зарегистрированные адреса устройств Пользователя) добавляются в набор Contact.

Если AOR уже существует в наборе AOR, то он не добавляется к набору AOR.

Если адрес уже существует в наборе Contact, то он не добавляется к набору Contact.

Модуль Signal проверяет каждый адрес и добавляет его к набору Contact.
Если новый адрес Contact является адресом Локального Узла, то Запрос передаётся на обработку в этот Узел.
Если новый адрес Contact является внешним адресом, то Запрос передаётся в Модуль SIP для релеинга.

Когда локальный или внешний участник возвращает Ответ типа Redirect, то модуль проверяет начальный AOR (URI Запроса).

Настройка Модуля Signal

Для того, чтобы настроить параметры модуля Signal, используйте Веб Интерфейс Администратора. Откройте в области Установки страницу Real-Time, затем откройте страницу Сигналы:

Обработка
Уровень Журнала: Процессоры: Ограничение на Объекты: Ограничение на События:
Уровень Журнала
Используйте эту настройку, чтобы указать, какую информацию компонент Signal должен сохранять в Журнале работы Сервера. Обычно используется уровень Сбои (только неразрешимые проблемы), уровень Основное (отчёты о ходе обработки Сигналов) или уровень Проблемы (сбои, отчёты о ходе обработки Сигналов и не фатальные ошибки).
В случае, если в работе компонента Signal возникают проблемы, возможно, целесообразным будет увеличить детализацию до уровня Подробности или Всё: в этом случае в Системный Журнал будет записываться более подробная информация о внутренней работе компонента. Когда проблема решена, верните настройку Уровень Журнала в её обычное значение, так как иначе Системный Журнал будет очень быстро увеличивать свой размер.
Записи, помещённые компонентом Signal в Журнал работы Сервера, имеют пометку SIGNAL.
Процессоры
Компонент Signal использует несколько одновременных процессоров (нитей) для обработки "задач" Сигналов. Один процессор может обрабатывать несколько задач Сигналов. Если вы используете большое количество Автоматических Правил, выполнение которых занимает относительно много времени, то вы должны разрешить компоненту использовать большее количество процессоров для обработки сигналов.
Ограничение на Объекты
Эта настройка определяет, какое количество "Задач" компонент Signal может обрабатывать одновременно.
При превышении этого ограничения новые Сигналы отвергаются и отправителям Сигналов направляется Ответ с кодом ошибки.
Ограничение на События
Эта настройка задаёт критическое число необработанных событий (отправленных во все активные "задачи" Сигналов).
При превышении этого ограничения компонент входит в режим перегрузки (Процессоры компонента не смогут обрабатывать возникающие события), новые Сигналы отвергаются и отправителям Сигналов направляется Ответ с кодом ошибки.

Используйте панель Установок Обработки, чтобы указать параметры обработки сигнальных задач.

Установки Обработки
Ограничение числа AOR: Ограничение по Времени:
Ограничение числа Разветвлений:   Аутентифицировать все исходящие
Ограничение числа AOR
Эта установка ограничивает количество AOR, которое может быть обработано в одной операции. Она ограничивает общее количество ответвлений, перенаправлений и т.п. для одного запроса.
Ограничение числа Разветвлений
Эта установка ограничивает количество ответвлений для одной операции.
Ограничение по Времени
Эта настройка задаёт ограничение по времени для обработки запроса.
Аутентифицировать все исходящие
Сервер CommuniGate Pro для определённых Запросов требует авторизации пользователя:
  • когда запросы отправляются удалённо через SIP, аутентификация выполняет в Модуле SIP
  • модули XIMSS и XMPP отправляют все Сигналы от имени зарегистрированного Пользователя, предварительно проведя аутентификацию
  • Приложения Реального Времени отправляют Сигналы от имени текущего Пользователя (если только Приложение не представляется как "никто")

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

Когда Сигнал, начинающий звонок (начальный запрос INVITE с дескриптором аудио/видео сессии), аутентифицирован, Модуль Signal проводит дополнительную обработку аутентифицированного Пользователя.

Компонент Signal может ограничить число "звонков", которое Пользователь может совершать в течение указанного периода времени. При попытке совершения большего количества звонков, они будут отвергаться без обработки.
Это ограничение может быть установлено индивидуально для каждого Пользователя, или же могут использоваться Общесерверные, Общекластерные или Доменные установки по умолчанию для Аккаунтов. Дополнительную информацию смотрите в разделе Пользователи.


Отправка Сигналов Пользователям

Если первый AOR в наборе (AOR, указанный в URI Запроса) является локальным адресом Пользователя, а Запрос имеет тип INVITE, то запрашивается регистрация устройства Пользователя и значения некоторых параметров из Установок и Настроек Пользователя.

У Пользователя могут быть настроены Автоматические Сигнальные Правила, которые запрашиваются одновременно с регистрациями устройств Пользователя. Эти Правила, наряду с Правилами, Общими для Домена пользователя, применяются ко всем запросам, отправляемым Пользователю.

Компонент Signal управляет количеством "звонков" (начальных INVITE запросов с Дескрипторами аудио/видео Сессий), которые Пользователь может принимать в течение заданного интервала времени. При получении большего количества запросов, они будут отвергаться без обработки.
Это ограничение может быть установлено индивидуально для каждого Пользователя, или же могут использоваться Общесерверные, Общекластерные или Доменные установки по умолчанию для Аккаунтов. Дополнительную информацию смотрите в разделе Пользователи.


Отправка Сигналов в Удалённые Системы

Если Сигнал должен быть ретранслирован в удалённую систему, то компонент Signal направляет его в какой-либо сигнальный модуль.

Адрес-получатель Сигнала может явно направляться в какой-либо модуль. Например, все домены с суффиксом ._xmpp направляются в модуль XMPP.

Если адрес-получатель Сигнала явно не направляется в какой-либо модуль, то компонент Signal проверяет имя домена, в котором находится адрес-получатель


Сервисные Звонки

Если запрос направлен на имя *nnnn в любой из локальных Доменов (где nnnn это любая последовательность, начинающаяся с десятичной цифры), то Запрос перенаправляется инициатору (на адрес From: Запроса).

Это возможность позволяет пользователю набирать номера *nnnn для получения от Сервера специальных услуг. Запрос направляется на Пользователя, у которого запускается сервисное приложение. Приложение обеспечивает требуемый сервис, получая значение набранной "опции сервиса" из адреса To: Запроса.


Услуги Регистрации

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

Запросы на Регистрацию требуют проведения Аутентификации Пользователя.

При изменения регистраций Пользователя могут использоваться Полномочия другого Пользователя, если аутентифицированный Пользователь имеет право доступа Может выступать от имени других для соответствующего Домена.

Для того, чтобы настроить Услуги Регистрации, откройте в области Установки страницу Real-Time и перейдите по ссылке Сигналы.

Услуги
Время Регистрации: Минимальное: По умолчанию: Максимальное:
Случайная поправка:  
MS RTC: Интегрировать с Ростером:
Регистрация: Минимальное
Используйте эту опцию для задания минимального периода времени срока действия Регистрации.
Если Запрос на Регистрацию имеет более короткий период действия, то Запрос отвергается и отправляется Ответ со значением минимально допустимого периода времени. Участник (обычно - SIP устройство) может переслать Запрос на Регистрацию с исправленным сроком действия.
Регистрация: По умолчанию
Значение этой опции используется, если в Запросе на Регистрацию не указан срок действия Регистрации.
Регистрация: Максимальное
Используйте эту опцию для задания максимального периода времени срока действия Регистрации.
Если Запрос на Регистрацию имеет более длительный срок, то он укорачивается до указанного здесь значения.
Регистрация: Случайная поправка
Если это опция установлена в ненулевое значение X, то запрошенное время срока действия Регистрации уменьшается на случайное значение от 0 до X.
Крупные сайты могут использовать эту возможность для смягчение "регистрационной бури", когда большое количество устройств начинает регистрироваться одновременно (после сбоя сети или остановки системы на обслуживание).
Запрошенное время срока действия уменьшается только если оно больше чем 2*X и больше чем Минимальное+X.

Обратите внимание: компонент Регистрации поддерживает расширения SIP gruu (Globally Routable User Agent (UA) URIs - глобально маршрутизируемые адреса пользовательских устройств).

Обратите внимание: Клиенты, использующие для регистрации имена доменов, начинающиеся с префиксов srtp. или dtls., помечаются как требующие шифрования медиа потока. Аналогично, если на сервере разрешены 'Детализированные' Адреса, и во время регистрации имя аутентификации в качестве детализации содержало строку srtp или dtls, то во входящих звонка этому Клиенту тоже будет предлагаться шифрование медиа потока.


Наборы Событий

Модуль Signal поддерживает несколько Наборов Событий. При получении Запроса SUBSCRIBE, предназначенного для локального Пользователя, модуль может обработать Запрос самостоятельно, не пересылая его зарегистрированным устройствам Пользователя.
Обратите внимание: как обходное решение для большого количества некорректно работающих клиентов, Модуль принимает Запросы SUBSCRIBE, отправленные в локальные Домены (вместо локальных Пользователей). В таких запросах, для замены адреса типа домен в адресе URI Запроса используется адрес в поле To.

Модуль Signal обслуживает "кортежи" состояний для каждого Пользователя и для каждого поддерживаемого Набора Событий. Модуль позволяет одному или нескольким устройствам обновлять "кортежи" и агрегирует их в единую для всего Набора "информацию о состоянии" Пользователя. Когда агрегированная "информация о состоянии" изменяется, модуль отправляет всем подписанным участникам запросы NOTIFY, содержащие обновлённое состояние.

Модуль Signal позволяет внешним участникам изменять "кортежи" используя запросы PUBLISH.

Модуль Signal позволяет внешним участникам изменять "кортежи" для определённых Наборов используя нестандартные запросы SERVICE.

Модуль Signal обеспечивает работу "наблюдателей" для всех Наборов Событий. Они обеспечивают информацию о подписчиках на "основные" Наборы Событий. Также реализованы наборы "наблюдателей за наблюдателями".

Если явно не указано иначе, подписка на Наборы Событий Пользователя возможна только для самого Пользователя и для Пользователей, обладающих Правами Доступа Может выступать от имени других в домене Пользователя, а также Пользователям с правом Delegate к этому Пользователю.
Такие же ограничения действуют на подписки к наборам "наблюдателей".

Статус Присутствия

В Модуле Signal реализован Сервер Статуса Присутствия. Модуль поддерживает форматы PIDF, CPIM-PIDF и XPIDF для информации о Статусе Присутствия.

Модуль Signal обеспечивает специальную обработку для запросов REGISTER. Если внешний участник (SIP устройство) указывает поддержку метода SUBSCRIBE, то модуль устанавливает с этим участником диалог подписки на статус присутствия.
Затем модуль обрабатывает все запросы NOTIFY, отправляемые этим участником для обслуживания "кортежа" или "сегмента" его Статуса Присутствия.

Значение сегмента статуса присутствия является одной из текстовых строк из фиксированного набора, перечисленных в порядке возрастания приоритета:

Агрегированное значение события - это значение сегмента с самым высоким приоритетом или значение offline ("вне сети"), если сегменты отсутствуют.

При формировании запроса NOTIFY агрегированное значение преобразовывается в документ статуса присутствия в одном из поддерживаемых форматов.

Подписка на этот Набор Событий доступна всем согласно стандартной схеме подтверждения.

Сводка о Сообщениях

В Модуле Signal реализован сервис MWI (Индикация Ожидающих Сообщений). Модуль поддерживает формат представления Информации simple-message-summary.

Сервер самостоятельно обслуживает кортеж/сегмент "INBOX" для этого набора Событий. Значение сегмента являются массивом:

Агрегированное значение события - это массив, содержащий поэлементную сумму всех значений массивов сегментов.

Когда формируется запрос NOTIFY, использующий информацию в формате simple-message-summary, то значение первого элемента агрегированного массива используется как число новых голосовых сообщений, а разница между значением второго и первого элементов используется как число старых голосовых сообщений.
Если значение первого элемента не равно нулю, то элемент Messages-Waiting устанавливается в значение yes; в противном случае оно сбрасывается в no.

Регистрация

В Модуле Signal реализована Услуга Мониторинга за Регистрацией. Модуль поддерживает формат представления Информации reginfo+xml и может информировать участников, находящихся в сети (таких, как SIP клиенты) обо всех других устройствах, зарегистрированных за Пользователем.

Диалог

В Модуле Signal реализована Услуга Мониторинга за Диалогом. Модуль поддерживает формат представления Информации dialog-info+xml и может информировать находящихся в сети участников (таких, как SIP клиенты) обо всех других активных диалогах Пользователя.

Подписка на набор Диалог возможна только для самого Пользователя, других Пользователей с правом Администратора Домена CanControlCalls (Полный доступ ко всем Звонкам), а также для тех Пользователей, которым Пользователь предоставил Право Доступа CallControl.


Звонки

Сервер CommuniGate Pro может создавать объекты Диалог при обработке определённых запросов INVITE. Объекты Диалог содержат информацию о звонке/сессии/диалоге, созданными этими запросами.
Объекты типа диалог уничтожаются по завершению звонков.

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

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

Если аутентифицированный участник (вызывающий или вызываемый) ставится на удержание, то используется его настройка Пользователя "Музыка при Ожидании".
Если она не установлена в выключено, то указанный звуковой файл читается из Хранилища Файлов Пользователя. Если имя файла задано как "*" или если указанный файл не найден, то читается файл HoldMusic из Среды для Приложений Реального Времени Домена Пользователя.
Когда звуковой файл прочитан, создаётся Медиа Канал и он получает задание на воспроизведение этого файла другому участнику.

Для того, чтобы настроить компонент Менеджер Диалога, используйте Веб Интерфейс Администратора. Откройте в разделе Установки страницу Real-Time, затем откройте страницу Сигналы:

Звонки
Уровень Журнала: Ограничение по Времени:
Тайм-аут по Сигналам: Тайм-аут по Медиа:
Уровень Журнала
Используйте эту настройку для того, чтобы указать, какую информацию компонент Менеджер Диалога должен сохранять в Журнале работы Сервера. Обычно используется уровень Сбои (только неразрешимые проблемы), уровень Основное (сбои и основные события) или уровень Проблемы (сбои, основные события и не фатальные ошибки).
Записи, помещённые компонентом Менеджер Диалога в Журнал работы Сервера, имеют пометку DIALOG.
Ограничение по Времени
Эта настройка задаёт ограничение по времени для Диалогов Звонка. При превышении этого лимита, объект Диалог удаляется. Устанавливайте значение для этого ограничения достаточно большим, чтобы избежать прерывания звонков.
Тайм-аут по неактивности, Тайм-аут по Медиа
Если в Диалоге не отправляется Сигналов в течение указанного периода времени, и, если осуществляется Проксирование Медиа, связанное с этим Диалогом, но в течение указанного периода времени отсутствуют медиа данные, то этот объект Диалог удаляется. Устанавливайте значения для этих ограничений достаточно большим, чтобы избежать прерывания звонков.

Журналы Звонков Пользователя

Журналы Звонков Пользователя сохраняются в виде текстовых файлов в Файловом хранилище Пользователя.

Записи в этих файлах имеют следующий формат:

2_dd-mmm hh:mm:ss_direction_peer_callId_callTime_alertTime_errorCode[_programName]
где:
_
символ табуляции (символ с кодом 0x09)
2
версия формата записи
dd
2-значный номер дня месяца
mmm
3-х символьное имя месяца
hh, mm, ss
2-значные цифры с часом (00..23), минутой (00..59) и секундой (00..59) окончания звонка
direction
1 символ направления звонка: I - входящий, O - исходящий
peer
адрес электронной почты участника звонка, в формате
  <username@domainName>
или
  "real name" <username@domainName>
callId
строка с Call-ID.
callTime
продолжительность звонка (в секундах). Время между моментом соединения и моментом рассоединения. Если звонок не был выполнен успешно, то это поле будет пустым.
alertTime
продолжительность вызова (в секундах). Время между началом звонка и моментом соединения или (если звонок не был выполнен успешно) время между началом звонка и моментом неуспешного завершения звонка.
errorCode
строка с кодом ошибки для неудачного звонка или причина рассоединения звонка. Если звонок был завершён успешно, то это поля является пустым.
programName
это необязательное поле содержит имя Приложения Реального Времени, которое обрабатывало этот звонок.

Детализированная Информация о Звонках (CDR)

Модуль Signal может генерировать Детализированную Информацию о Звонках для обрабатываемых им транзакциях INVITE и BYE. Он может также генерировать Детализированную Информацию о Звонках для выполненных звонков, используя информацию из объектов Диалог.

CDR может генерироваться и храниться в Дополнительном Журнале CDR.

Наблюдение
Записывать CDR для Звонков Записывать Invite/BYE CDR
Записывать CDR для Звонков
Выберите эту опцию для того, чтобы включить создание файлов Журнала CDR для Звонков (объектов Диалога).
Записывать Invite/BYE CDR
Выберите эту опцию для того, чтобы включить созданий файлов Журнала CDR для запросов INVITE и BYE.

Когда включена программа Помощник Внешний Обработчик CDR, то Модуль Signal генерирует CDR всех типов и отправляет их в эту программу.

Текстовые данные CDR для запросов INVITE/BYE имеют следующий формат (для разделения полей используется символ табуляции):
01 NNN-method dialog-identifier parties network-addresses flags
где:
01
версия используемого формата CDR
NNN
код выполнения транзакции (цифровой)
Method
операция/метод транзакции (INVITE, BYE).
dialog-identifier
идентификатор диалога - поле Call-ID, параметр tag поля From, параметр tag поля To), заключённые в угловые скобки < и >.
Обратите внимание: Если вызов прерван вызываемым абонентом, то fromTag транзакции BYE совпадает с toTag транзакции INVITE и наоборот.
parties
адреса URI из полей From и To транзакции, заключённые в угловые скобки < и >.
network-addresses
сетевой адрес (IP), с которого получен был получен запрос на транзакцию, в квадратных скобках [ и ].
flags
необязательные поля, разделённые символом табуляции:
[auth:accountName]
элемент добавляется, если запрос в транзакции был аутентифицирован. Имя аутентифицированного Пользователя CommuniGate Pro - accountName.
[redir:accountName]
этот элемент добавляется, если запрос в транзакции был перенаправлен с локального Пользователя. Имя Пользователя CommuniGate Pro, перенаправившего запрос, - accountName.
[billing:billingData]
этот элемент добавляется, если запрос в транзакции имеет поле P-Billing-Id. Строка billingData является содержимым поля.
[referred:referredby]
этот элемент добавляется если запрос в транзакции имеет поле Referred-By. Строка referredby является содержимым поля.
Текстовые данные CDR для запросов INVITE/BYE имеют следующий формат (для разделения полей используется символ табуляции):

02 callType accountName alertTime connectTime reason dialog-identifier ["fromName"] <from> ["toName"] <to>[[toProgramName]] flags
где:
02
версия используемого формата CDR
callType
тип вызова (INP, OUT).
accountName
полное имя Пользователя (accountName@domainName).
alertTime
интервал времени (в секундах) между временем, когда звонок был инициирован и временем, когда звонок был принят или отвергнут.
connectTime
интервал времени (в секундах) между временем, когда звонок был принят и временем, когда звонок был завершён. Если звонок не был принят, то в этом поле содержится символ - (минус).
reason
причина, по которой звонок был отвергнут или завершён.
dialog-identifier
идентификатор диалога - поле Call-ID, параметр tag поля From, параметр tag поля To), заключённые в угловые скобки < и >.
from, to
адреса URI полей From и To транзакции.
fromName, toName
значение "Настоящее Имя" полей From и To транзакции. Все другие поля являются необязательными. Если они заданы, то заключены в двойные кавычки (").
toProgramName
необязательно - имя PBX Приложения, принявшего звонок.
flags
аналогично используемым с записями версии 01.

Узлы Обработки Сигналов

Сервер CommuniGate Pro динамически создаёт, запускает и удаляет Узлы обработки сигналов Реального Времени.

Узел - это внутренний объект Сервера CommuniGate Pro, который может получать Запросы Сигналов и давать Ответы на эти Запросы. Узел также может отправлять Запросы и обрабатывать Ответы.

Различные компоненты и модули CommuniGate Pro используют Узлы для работы с Сигналами:

Для того, чтобы настроить параметры компонента Узлы, используйте Веб Интерфейс Администратора. Откройте в разделе Установки страницу Real-Time, затем откройте страницу Узлы:

Обработка
Уровень Журнала: Процессоры: Ограничение на Объекты: Ограничение на События:
Уровень Журнала
Используйте эту настройку для того, чтобы указать, какую информацию компонент Узлы должен сохранять в Журнале работы Сервера. Обычно используется уровень Сбои (только неразрешимые проблемы), уровень Основное (сбои и основные события) или уровень Проблемы (сбои, основные события и не фатальные ошибки). В случае, если в работе компонента Узлы возникают проблемы, возможно, целесообразным будет увеличить детализацию до уровня Подробности или Всё: в этом случае в Системный Журнал будет записываться более подробная информация о внутренней работе компонента. Когда проблема решена, верните настройку Уровень Журнала в её обычное значение, так как иначе Системный Журнал будет очень быстро увеличивать свой размер.
Записи, помещённые компонентом Узлы в Журнал работы Сервера, имеют пометку NODE.
Процессоры
Компонент Узлы использует несколько одновременных процессоров (нитей) для обработки "задач" Сигналов. Один процессор может обрабатывать несколько задач Узлов.
Если вы используете большое количество Узлов, операции которых занимают относительно много времени (Приложения Реального Времени и т.п.), то вы должны разрешить компоненту использовать большее количество процессоров.
Ограничение на Объекты
Эта настройка определяет, какое количество Узлов компонент может обрабатывать одновременно. Если это число превышено, то попытки создать новый Узел приведут к ошибке.
Ограничение на События
Эта настройка задаёт критическое число необработанных событий (отправленных во все активные Узлы). При превышении этого ограничения компонент входит в режим перегрузки (Процессоры компонента не смогут обрабатывать возникающие события), и попытка создания новых Узлов приведёт к ошибке.

Плечи Звонка

Сервер создаёт специальные Узлы Обработки Сигналов, называемые Плечи Звонка. Каждое Плечо Звонка терминирует сигналы для одного телефонного звонка. Каждая Задачи PBX является Плечом Звонка и каждая XIMSS сессия может создавать одно или более Плечо Звонка для обслуживания телефонных звонков, инициированных или принятых в XIMSS сессии пользователя.

Настройки на панели Плечи Звонков применяются для всех типов Плечей Звонков:

Плечи Звонков
Тайм-аут: Минимальное: По умолчанию:
Ограничение Релеинга:
Тайм-аут
Используйте эту настройку для указания частоты обмена сторонами запросами INVITE (или OPTION) для проверки того, что звонок не разъединился.
Ограничение Релеинга
Используйте эту настройку для задания значения поля Max-Forwards для запросов, отправляемых в Плечах Звонка.

Интерфейс к Сигналам (API)

Задачи Сигналов могут получать "события" от других компонентов CommuniGate Pro, таких, как задачи CG/PL и клиентские сессии XIMSS. Для того, чтобы отправить событие, отправитель должен получить описатель сигнала.

Задача Сигналов принимает следующие события:

decline
Это события заставляет задачу Сигналов прекратить обработку Сигнального Запроса и отвергнуть его с кодом ошибки 603 Отвергнуто.
fork
Данные этого события должны быть строкой или массивом строк. Сигнальный Запрос ответвляется на URI, задаваемые этими строками.
redirect
Аналогично fork, но все текущие "ответвлённые" Запросы прекращаются.

Руководство CommuniGate® Pro. Copyright © 1998-2017, Stalker Software, Inc.