CommuniGate Pro
Версия 6.0
Сигналы
 
 
Обзор

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

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

Для каждого Запроса, модуль 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 может обрабатывать одновременно. При превышении этого ограничения новые Сигналы отвергаются и отправителям Сигналов направляется Отклик с ошибкой.
Ограничение на События
Эта настройка задаёт критическое число необработанных событий (отправленных во все активные "задачи" Сигналов). При превышении этого ограничения компонент входит в режим перегрузки (Процессоры компонента не смогут обрабатывать возникающие события), новые Сигналы отвергаются и отправителям Сигналов направляется Отклик с ошибкой.

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

Сервер 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 проверяет имя домена, в котором находится адрес-получатель.


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

Если запрос направлен на имя *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" для этого набора Событий. Значение сегмента являются
массивом:

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

Когда формирует запрос 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 используют Узлы для работы с Сигналами:

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

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

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

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

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

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

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

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

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

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

hh:mm:ss.ddd cdr_data
где hh - это час, mm - минута, ss - секунда, а ddd - миллисекунда того момента, когда была создана запись CDR; cdr_data - это данные CDR.
Наблюдение
Записывать CDR для Звонков Записывать Invite/BYE 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.

API к Сигналам

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

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

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

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