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

Пользователи могут настроить свои устройства (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 могут использовать Сигналы:

Субкомпонент сервера SIP Модуль получает Запросы от внешних участников коммуникаций Реального Времени (SIP клиенты, другие SIP сервера), используя SIP протокол. Когда Модуль Signal генерирует объект с Откликом, SIP Модуль отправляет отклик обратно внешнему участнику.
XMPP Модуль и XIMSS Модуль отправляют и получают Сигнальные Запросы и Отклики, а также передают между их между клиентскими приложениями и Сервером CommuniGate Pro.
Внутренние Узлы Реального Времени, такие как Программы Реального Времени (Приложения PBX) могут отправлять различные Сигнальные запросы.
Правила Автоматической Обработки могут использовать Сигналы (отправлять Мгновенные Сообщения как уведомления).

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

Маршрутизатор вернул код ошибки (например, URI Запроса адресуется несуществующему локальному Пользователю). Этот код ошибки возвращается источнику Сигнала, и обработка останавливается.
Маршрутизатор вернул не локальный адрес (адрес не из локального Домена). Запрос передается в SIP Модуль для релеинга. Отклик, возвращенный SIP модулем, передаётся источнику Сигнала.
Маршрутизатор вернул адрес локального внутреннего Узла Реального Времени. Запрос передаётся на обработку в этот Узел. Отклик, возвращенный Узлом, передается источнику Сигнала.
Маршрутизатор вернул локальный адрес Пользователя и Запрос может быть обработан Модулем Signal самостоятельно. Запрос обрабатывается и Отклик возвращается источнику Сигнала. Эти случаи включает в себя также Запросы типа REGISTER и другие Запросы, URI которых предназначаются для локальных Доменов.
Маршрутизатор вернул локальный адрес и Запрос не может быть обработан Модулем Signal самостоятельно. Начинается процесс Подключения, URI Запроса используется в качестве начального набора AOR.

Следующая диаграмма иллюстрирует направление Сигналов в Сервере 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 Запроса).

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

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

Обработка
Уровень Журнала:	Процессоры:	Ограничение на Объекты:	Ограничение на События:

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

Сервер CommuniGate Pro для определённых Запросов требует авторизации пользователя.

Когда запросы отправляются удалённо через SIP, аутентификация выполняет в SIP Модуле.
Модули XIMSS и XMPP отправляют все Сигналы от имени зарегистрированного Пользователя, предварительно проведя аутентификацию.
Приложения Реального Времени отправляют Сигналы аутентифицировавшись от имени текущего Пользователя (если только Приложение не представляется как "никто").

Аутентифицировать все исходящие: Если указана эта опция, то компонент Signal пытается проводить Маршрутизацию для всех адресов в полях From в запросах типа Call. Если адрес From является локальным адресом Пользователя и запрос не аутентифицирован, то компонент Signal отвергает его с кодом ошибки "authentication required".

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

Компонент Signal может ограничить число "звонков", которое Пользователь может совершать в течении указанного периода времени.

Ограничение Потока
Отвергать исходящие если сделано более	за

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

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

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

Компонент Signal управляет количеством "звонков" (начальных INVITE запросов с аудио/видео Дескрипторами Сессии), которые Пользователь может принимать в течении заданного интервала времени.

Ограничение Потока
Отвергать исходящие если сделано более	за

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

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

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

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

Если имя домена является IP адресом, то Сигнал направляется в SIP модуль.
Если имя домена имеет в DNS записи SIP SRV, то Сигнал направляется в SIP модуль.
Если имя домена имеет в DNS записи XMPP SRV, то Сигнал направляется в XMPP модуль.
Во всех других случаях Сигнал направляется в SIP модуль.

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

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

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

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

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

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

Услуги
Время Регистрации:	Минимальное:	По умолчанию:	Максимальное:
Время Регистрации:	Случайная поправка:
MS RTC:	Интегрировать с Ростером:

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

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

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

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

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

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

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

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

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

Вне сети
Нет на месте
На перерыве
На совещании
Скоро вернусь
В сети
На телефоне
Занят(а)

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

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

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

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

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

первый элемент - это число сообщений в INBOX, имеющих флаг $Media и не имеющих флага Seen (число непрочитанных медиа сообщений);
второй элемент - это общее число сообщений в INBOX, имеющих флаг $Media (общее число медиа сообщений);

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

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

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

Регистрация

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

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

Диалог

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

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

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

Запрос INVITE создаёт объект Диалог в случае, если выполняется любое из следующих условий:

отправитель запроса аутентифицирован;

адресат запроса является локальным Пользователем;

Проксирование Медиа необходимо для обработки звонка;

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

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

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

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

Диалоги-Звонки
Уровень Журнала:		Ограничение по Времени:
Тайм-аут по Сигналам:		Тайм-аут по Медиа:

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

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

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

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

Компонент Приложения Реального Времени создаёт Узел для каждого "плеча звонка".
Модули MAPI и WebUser создают Узлы Реального Времени для реализации функции "Совершить Звонок". Узел, создаваемый этими модулями, отправляет Запросы для совершения звонка между сессией пользователя и указанным адресом.
SIP Модуль создаёт Узел и использует его для отправки Запросов на Регистрацию на Внешние Шлюзы для обслуживания Регистрации Сервера на этих Шлюзах.
Субкомпонент Статус Присутствия создаёт Узел и использует его для обслуживания Подписок на События Статуса Присутствия для устройств, которые не могут обновлять своё состояние Присутствия.

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

Обработка
Уровень Журнала:	Процессоры:	Ограничение на Объекты:	Ограничение на События:

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

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

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

Плечи Звонков
Тайм-аут:	Минимальное:	По умолчанию:
Ограничение Релеинга:
Объявлять UPDATE:		Посылать UPDATE:

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

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

CDR может генерироваться и храниться в файлах Журнала CDR.
Файлы Журнала CDR создаются в поддиректории CDR внутри поддиректории SystemLogs директории данных Сервера.
Файлы Журнала CDR являются текстовыми файлами, каждая запись находится на отдельной строке.

Каждая строка CDR имеет следующий формат:

hh:mm:ss.ddd cdr_data

Наблюдение
Записывать CDR для Звонков	Записывать Invite/BYE CDR

где hh - это час, mm - минута, ss - секунда, а ddd - миллисекунда того момента, когда была создана запись CDR; cdr_data - это данные CDR.

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

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

Текстовые данные CDR для запросов INVITE/BYE имеют следующий формат:

01 NNN-method <callID><fromTag><toTag> <from><to> [reqIP][respIP] flags

где:

01

версия используемого формата CDR

NNN

код выполнения транзакции (цифровой)

Method

операция/метод транзакции (INVITE, BYE).

callID, fromTag, toTag

Идентификатор диалога (поле Call-ID, поле From параметр tag, поле To параметр tag).
Обратите внимание: Если вызов прерван вызываемым абонентом, то fromTag транзакции BYE совпадает с toTag транзакции INVITE и наоборот.

from, to

URI поле From и To транзакции.

reqIP

сетевой (IP) адрес, с которого получен был получен запрос на транзакцию.

respIP

сетевой (IP) адрес, с которого получен отклик.

flags

дополнительные элементы, разделённые символом пробел:

[auth:accountName]: этот элемент добавляется если запрос на транзакцию был аутентифицирован. accountName это имя аутентифицированного Пользователя CommuniGate Pro.
[redir:accountName]: этот элемент добавляется если запрос на транзакцию был перенаправлен с локального Пользователя. accountName - это имя этого Пользователя CommuniGate Pro.
[billing:billingData]: этот элемент добавляется, если запрос на транзакцию имеет поле P-Billing-Id. Строка billingData является содержанием поля.
[referred:referredby]: этот элемент добавляется если запрос на транзакцию имеет поле Referred-By. Строка referredby является содержанием поля.

Текстовые данные CDR для звонков имеют следующий формат:

02 callType accountName alertTime connectTime reason <callID><fromTag><toTag> ["fromName"] <from> ["toName"]<to>[[toProgramName]] flags

где:

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

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

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

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

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

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

Регистрация

Диалог

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

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

Сигналы

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

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

Подключение

Конфигурирование Компонента Signal

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

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

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

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

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

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

Диалоги

Локальные Узлы

Плечи Звонков

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

API к Сигналам