Пользователи могут настроить свои устройства (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.
- Маршрутизатор вернул фиктивный адрес null. Положительный ответ (код OK) возвращается источнику Сигнала, и обработка останавливается.
Следующая диаграмма иллюстрирует схему обработки Сигналов в Сервере 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.
- Процессоры
- Компонент Signal использует несколько одновременных процессоров (нитей) для обработки "задач" Сигналов. Один процессор может обрабатывать несколько задач Сигналов. Если вы используете большое количество Автоматических Правил, выполнение которых занимает относительно много времени, то вы должны разрешить компоненту использовать большее количество процессоров для обработки сигналов.
- Ограничение на Объекты
- Эта настройка определяет, какое количество "Задач" компонент Signal может обрабатывать одновременно.
При превышении этого ограничения новые Сигналы отвергаются и отправителям Сигналов направляется Ответ с кодом ошибки.
- Ограничение на События
- Эта настройка задаёт критическое число необработанных событий (отправленных во все активные "задачи" Сигналов).
При превышении этого ограничения компонент входит в режим перегрузки (Процессоры компонента не смогут обрабатывать возникающие события), новые Сигналы отвергаются и отправителям Сигналов направляется Ответ с кодом ошибки.
Используйте панель Установок Обработки, чтобы указать параметры обработки сигнальных задач.
- Ограничение числа AOR
- Эта установка ограничивает количество AOR, которое может быть обработано в одной операции. Она ограничивает общее количество ответвлений, перенаправлений и т.п. для одного запроса.
- Ограничение числа Разветвлений
- Эта установка ограничивает количество ответвлений для одной операции.
- Ограничение по Времени
- Эта настройка задаёт ограничение по времени для обработки запроса.
- Аутентифицировать все исходящие
- Сервер CommuniGate Pro для определённых Запросов требует авторизации пользователя:
- когда запросы отправляются удалённо через SIP, аутентификация выполняется в Модуле SIP
- модули XIMSS и XMPP отправляют все Сигналы от имени зарегистрированного Пользователя, предварительно проведя аутентификацию
- Приложения Реального Времени отправляют Сигналы от имени текущего Пользователя (если только Приложение не представляется как "никто")
Эта опция требует аутентификации всех звонков (начальных запросов INVITE), начатых от имени Пользователей этого Сервера.
Когда Сигнал, начинающий звонок (начальный запрос 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 и перейдите по ссылке Сигналы.
- Регистрация: Минимальное
- Используйте эту опцию для задания минимального периода времени срока действия Регистрации.
Если Запрос на Регистрацию имеет более короткий период действия, то Запрос отвергается и отправляется Ответ со значением минимально допустимого периода времени. Участник (обычно - 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 - вне сети
- away - нет на месте
- out-lunch - на перерыве
- in-meeting - на совещании
- be-back - скоро вернусь
- online - в сети
- on-phone - на телефоне
- busy - занят
Агрегированное значение события - это значение сегмента с самым высоким приоритетом или значение offline ("вне сети"), если сегменты отсутствуют.
При формировании запроса 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 клиенты) обо всех других активных диалогах Пользователя.
Подписка на набор Диалог возможна только для самого Пользователя, других Пользователей с правом Администратора Домена 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
- это необязательное поле содержит имя Приложения Реального Времени, которое обрабатывало этот звонок.
Модуль Signal может генерировать Детализированную Информацию о Звонках для обрабатываемых им транзакциях INVITE и BYE. Он может также генерировать Детализированную Информацию о Звонках для выполненных звонков, используя информацию из объектов Диалог.
CDR может генерироваться и храниться в Дополнительном Журнале 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 используют Узлы для работы с Сигналами:
- Компонент Приложения Реального Времени создаёт Узел для каждого "плеча звонка".
- Сессии XIMSS создают Узел для каждого "плеча звонка" XIMSS.
- Субкомпонент Статус Присутствия создаёт Узел и использует его для обслуживания Подписок на События Статуса Присутствия для устройств, которые не могут обновлять своё состояние Присутствия.
Для того, чтобы настроить параметры компонента Узлы, используйте Веб Интерфейс Администратора. Откройте в разделе Установки страницу Real-Time, затем откройте страницу Узлы:
- Уровень Журнала
- Используйте эту настройку для того, чтобы указать, какую информацию компонент Узлы должен сохранять в Журнале работы Сервера. Обычно используется уровень Сбои (только неразрешимые проблемы), уровень Основное (сбои и основные события) или уровень Проблемы (сбои, основные события и не фатальные ошибки). В случае, если в работе компонента Узлы возникают проблемы, возможно, целесообразным будет увеличить детализацию до уровня Подробности или Всё: в этом случае в Системный Журнал будет записываться более подробная информация о внутренней работе компонента. Когда проблема решена, верните настройку Уровень Журнала в её обычное значение, так как иначе Системный Журнал будет очень быстро увеличивать свой размер.
Записи, помещённые компонентом Узлы в Журнал работы Сервера, имеют пометку NODE.
- Процессоры
- Компонент Узлы использует несколько одновременных процессоров (нитей) для обработки "задач" Сигналов. Один процессор может обрабатывать несколько задач Узлов.
Если вы используете большое количество Узлов, операции которых занимают относительно много времени (Приложения Реального Времени и т.п.), то вы должны разрешить компоненту использовать большее количество процессоров.
- Ограничение на Объекты
- Эта настройка определяет, какое количество Узлов компонент может обрабатывать одновременно. Если это число превышено, то попытки создать новый Узел приведут к ошибке.
- Ограничение на События
- Эта настройка задаёт критическое число необработанных событий (отправленных во все активные Узлы). При превышении этого ограничения компонент входит в режим перегрузки (Процессоры компонента не смогут обрабатывать возникающие события), и попытка создания новых Узлов приведёт к ошибке.
Сервер создаёт специальные Узлы Обработки Сигналов, называемые Плечи Звонка. Каждое Плечо Звонка терминирует сигналы для одного телефонного звонка. Каждая Задачи PBX является Плечом Звонка и каждая XIMSS сессия может создавать одно или более Плечо Звонка для обслуживания телефонных звонков, инициированных или принятых в XIMSS сессии пользователя.
Настройки на панели Плечи Звонков применяются для всех типов Плечей Звонков:
- Тайм-аут
- Используйте эту настройку для указания частоты обмена сторонами запросами INVITE (или OPTION) для проверки того, что звонок не разъединился.
- Ограничение Релеинга
- Используйте эту настройку для задания значения поля Max-Forwards для запросов, отправляемых в Плечах Звонка.
Задачи Сигналов могут получать "события" от других компонентов CommuniGate Pro, таких, как задачи CG/PL и клиентские сессии XIMSS. Для того, чтобы отправить событие, отправитель должен получить описатель сигнала.
Задача Сигналов принимает следующие события:
- decline
- Это события заставляет задачу Сигналов прекратить обработку Сигнального Запроса и отвергнуть его с кодом ошибки 603 Отвергнуто.
- fork
- Данные этого события должны быть строкой или массивом строк. Сигнальный Запрос ответвляется на URI, задаваемые этими строками.
- redirect
- Аналогично fork, но все текущие "ответвлённые" Запросы прекращаются.
|
