Установка и эксплуатация

Редакция 2026-09-29 Действует с 2026-09-29

Правообладатель: ООО "Современные системы автоматизации".

Редакция: 29.09.2026.

Область применения: опубликованная контейнерная поставка 0.68.0 с отдельными папками-юнитами. Применимость к конкретной установке определяется её фактической версией и составом.

1. Назначение

Руководство предназначено для администратора установки и пользователей платформы. Облачному пользователю не требуется развёртывать серверные компоненты: адрес и учётные данные предоставляет поставщик. Административные команды выполняются на выделенном Linux-сервере пользователем с правом управления Docker.

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

2. Требования

2.1. Сервер и рабочее место

Параметр Требование
Архитектура Linux x86_64 / amd64.
ОС В качестве базовой среды используется Ubuntu 24.04 LTS. Перед применением другого дистрибутива проверить совместимость Docker, сетевых настроек и компонентов выбранной поставки.
CPU От 2 ядер; рекомендуемый ориентир 8 ядер.
RAM От 4 ГБ без приложений-стратегий; от 6 ГБ со стратегиями. Рекомендуемый ориентир 16 ГБ.
Накопитель От 30 ГБ SSD; рекомендуемый ориентир 200 ГБ SSD. Запас зависит от записей, вложений и срока хранения.
Контейнерная среда Docker Engine 24+ и плагин Docker Compose v2.20+. Для старой конфигурации с директивой include требуется не ниже 2.20.3.
Адресация Статический публичный IP для описанного внешнего SIP-подключения. Домен и корректный DNS необходимы для публично доверенного TLS и подключений с внешними HTTPS-webhook.
Рабочее место Браузер с JavaScript и WebSocket. Для браузерного телефона дополнительно WebRTC, микрофон и гарнитура. Для базового теста можно использовать внешние SIP-софтфоны.

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

Для миниатюр вложений в чатах бинарные библиотеки требуют инструкций уровня x86-64-v2. У виртуальной машины проверить проброс возможностей CPU, в частности SSE4.2 и POPCNT. Согласно описанию выпуска, отсутствие этих возможностей ограничивает миниатюры, а не всю телефонию.

2.2. Сеть

Порты по умолчанию Назначение
5060/UDP, TCP SIP-телефоны и софтфоны.
5080/UDP, TCP SIP-транки провайдеров.
5061/TCP SIP поверх TLS.
8443/TCP SIP через WebSocket для браузерных звонков.
30000-30500/UDP Голосовой медиатрафик.
80/TCP, 443/TCP Веб-интерфейс и HTTPS; использование HTTP определяется конфигурацией.

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

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

3. Подготовка

  1. Получить у правообладателя учётную запись чтения реестра и согласованный тег поставки.
  2. Подготовить отдельный сервер и установить Docker из официального репозитория для выбранной ОС вместе с Compose.
  3. Проверить версии и ресурсы:
docker version
docker compose version
nproc
free -h
df -h /
  1. До первого запуска отключить прокси портов Docker. По умолчанию Docker запускает на сервере по два процесса docker-proxy на каждый опубликованный порт; для диапазона голосового трафика (501 порт) это от 0,6 до 2,3 ГБ оперативной памяти в зависимости от версии Docker, которые не учитываются в ограничениях контейнеров и не отображаются в docker stats. На сервере с минимальными ресурсами это может привести к исчерпанию памяти. В файл /etc/docker/daemon.json добавить ключ "userland-proxy": false (сохранив имеющиеся ключи) и перезапустить службу:
sudo systemctl restart docker
pgrep -c docker-proxy

Ожидаемый результат второй команды — 0. На работающей установке перезапуск службы Docker перезапускает все контейнеры, поэтому выполняется в согласованное окно. Фактический расход показывает ./omniflow-ctl doctor, шаг «прокси портов docker»; подробности — раздел «Прокси портов Docker» файла INSTALL.md.

Дальнейшие команды выполнять от одного пользователя с правом доступа к Docker. Не смешивать обычный запуск и sudo docker: учётные данные реестра хранятся раздельно. Членство в группе Docker предоставляет широкие полномочия на сервере и выдаётся только администратору.

docker login registry.omniflow.ru
docker pull registry.omniflow.ru/omniflow/ctl:0.68.0

При ошибке проверить реквизиты, права чтения, DNS и исходящий HTTPS. Не использовать административные реквизиты реестра вместо учётной записи чтения.

4. Установка и запуск

Команды предназначены для новой установки. Для существующей инсталляции используйте порядок из раздела 13 "Обновление".

sudo mkdir -p /app/omniflow
sudo chown "$USER":"$(id -gn)" /app/omniflow
cd /app/omniflow

docker run --rm -it --pull always \
  -v "$PWD:/install" -e CTL_HOST_DIR="$PWD" \
  registry.omniflow.ru/omniflow/ctl:0.68.0 install

Установщик предлагает состав компонентов, показывает будущую структуру каталогов, запрашивает подтверждение, внешний IP и адрес веб-интерфейса. Сохранить выданные административные реквизиты защищённо. Режим без интерактивного терминала описан в поставляемом INSTALL.md.

Структура новой установки:

Каталог Назначение
infra/ БД, шина, S3-совместимое хранилище и вспомогательные сервисы.
core/ Ядро OmniFlow.
sbc-1/ SIP-контур с Kamailio и SBC Agent.
cu-1/ Медиа-узел с Asterisk и CU Agent.
rtpe-1/ Медиапрокси rtpengine и RTPE Agent.
web/ Веб-интерфейс и публичный веб-вход.
strategies-<тенант>/ Подключаемые отдельно приложения-стратегии организации.
shared/ Общие данные, в том числе промежуточные записи разговоров.

У каждого юнита свой compose-проект; в корне новой установки нет общего docker-compose.yml. Параметры всей инсталляции находятся в .env; дополнительные настройки юнитов - в их файлах.

Проверить .env локально, не публикуя секреты:

Параметр Значение
EXTERNAL_IP Публичный IP сервера.
PUBLIC_DOMAIN Домен веб-интерфейса либо IP для ограниченного варианта без домена.
SIP_DOMAIN Платформенный параметр. SIP-домен конкретной линии равен коду её организации; не путать его с адресом сервера.
OMNIFLOW_VERSION 0.68.0 для описываемой поставки.
TLS_MODE self-signed, letsencrypt либо custom по выбранной схеме.

По умолчанию установщик создаёт индивидуальный самоподписанный сертификат. Для доступа пользователей через интернет подготовить сертификат доверенного центра сертификации; для внутреннего доступа можно использовать корпоративный центр, которому доверяют рабочие устройства. Не использовать обход предупреждений браузера как постоянный порядок работы. В новой раскладке сертификаты находятся в infra/config/tls/; пути и имена файлов выбранного режима сверить с .env.example. Старые пути apps/shared-tls/ относятся к прежней раскладке.

./omniflow-ctl up
./omniflow-ctl ps
./omniflow-ctl verify

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

Для подробной диагностики:

./omniflow-ctl doctor
./omniflow-ctl logs infra migrator
./omniflow-ctl logs core-node --tail 100

doctor не является исключительно чтением состояния: утилита может обновлять файлы поставки. Одноразовые сервисы миграций и подготовки TLS могут штатно завершаться с кодом 0; постоянно работающие сервисы не должны находиться в цикле перезапуска.

5. Организация, линии и стратегии

После установки создать организацию и две SIP-линии через веб-интерфейс либо консоль. В примере используются новая организация demo и линии 701 и 702. Для существующей организации подставить её код и свободные номера линий; повторно создавать её не требуется.

./omniflow-ctl tenant create demo --name "Demo"
./omniflow-ctl sipuser add 701 --tenant demo
./omniflow-ctl sipuser add 702 --tenant demo

Подключить два телефона с выданными параметрами. Адрес сервера и порт берутся из страницы подключения; Domain/Realm равен коду организации (demo в примере), а не публичному домену веб-интерфейса. Выполнить внутренний звонок, проверить звук в обе стороны, историю и запись. Не направлять тестовые вызовы во внешние платные направления без согласования.

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

./omniflow-ctl strategies catalog
./omniflow-ctl strategies add queue-operator --tenant demo
./omniflow-ctl strategies list

Настройка очереди, её расписания, операторов и маршрута выполняется отдельно. Наличие запущенной стратегии не означает готовность всей очереди.

Речевой шлюз отсутствует в стандартной поставке 0.68.0. Для распознавания, синтеза и диалога с роботом отдельно развёртываются шлюз и приложение-стратегия и настраиваются речевые провайдеры. Для внутренней телефонии эти подключения не требуются.

6. Завершение подготовки

Зафиксировать фактические версии платформы и стратегий, состав образов и digest, среду и результаты проверки. Успешный verify не заменяет функциональный тест аудио, текстового канала или разграничения доступа.

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

Источники: инструкция и версии поставки, история выпусков, поставляемый INSTALL.md.

Поддержка: support@omniflow.ru, будние дни с 09:00 до 18:00 по московскому времени.

7. Настройка работы

7.1. Пользователи

В "Настройки / Пользователи" нажать "Добавить", задать логин, имя, пароль и роли. Для оператора выбрать роль operator, затем в редактировании пользователя связать его с SIP-пользователем и сохранить.

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

Управление организациями и общесистемным состоянием относится к полномочиям администратора платформы. Администраторы организаций и операторы работают в пределах выданных ролей; общесистемные права им не требуются.

7.2. Транк и маршрутизация

  1. Получить у оператора связи параметры подключения и разрешённые направления вызовов.
  2. Открыть "Телефония / Транки", создать транк, выбрать SBC-контур, указать код и название.
  3. Выбрать тип подключения. Для регистрации указать сервер, SIP-домен, логин и пароль; для подключения по IP указать адреса провайдера и параметры исходящего направления согласно выданным условиям.
  4. Сохранить транк и проверить его состояние. Входящую доступность и регистрацию оценивать раздельно.
  5. В "Телефония / Маршрутизация" создать правило: направление, условия по транку/номерам, вес, действие и цель. Для исходящего правила на транк SIP-контур определяется выбранным транком. Активировать только согласованные правила.
  6. Проверить сопоставление номера встроенным тестером маршрутов, затем выполнить разрешённые входящий и исходящий тестовые вызовы.

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

7.3. Очереди и стратегии

  1. Создать активных пользователей с ролью оператора и привязать их SIP-точки.
  2. В "Настройки / Очереди" создать очередь, указать код, название и операторов; настроить расписание и действия его периодов.
  3. Подключить необходимое приложение-стратегию к своей организации и проверить его состояние в разделе "Стратегии". На сервере это выполняет администратор установки командой ./omniflow-ctl strategies add <код> --tenant <тенант>. Каталог доступен через strategies catalog, установленные приложения - через strategies list. Параметры, файлы и расписание настраиваются отдельно.
  4. Направить нужное правило маршрутизации в эту очередь.
  5. Проверить вызов при доступном операторе, отсутствии ответа и вне рабочего времени. Результат должен соответствовать выбранной стратегии и расписанию.

Для стандартного распределения оператор должен быть активен, иметь доступную SIP-точку и подходящий бизнес-статус. Недоступность операторов не должна приводить к бесконтрольной отправке тестовых вызовов во внешнюю сеть.

8. Работа оператора

  1. Войти под собственной учётной записью и открыть "Рабочее место".
  2. Для браузерной телефонии разрешить доступ к микрофону, проверить гарнитуру и состояние подключения. Установить статус готовности к приёму обращений.
  3. Выбрать обращение в списке либо принять входящий вызов с помощью элементов управления звонком на рабочем месте.
  4. Просмотреть карточку клиента и контекст обращения, выполнить разговор или переписку. При необходимости добавить заметку.
  5. Указать результат обработки с помощью доступных действий веб-интерфейса. Завершение телефонного соединения и завершение обработки обращения могут быть отдельными действиями.
  6. При перерыве изменить бизнес-статус, чтобы не оставаться доступным для распределения.

Для просмотра завершённых вызовов администратор или супервизор использует "История звонков". Для текущих соединений предусмотрен раздел "Активные звонки". Доступность отдельных действий зависит от ролей и контекста обращения.

9. Дополнительные подключения

9.1. Чаты

Подключать только провайдеров, включённых в согласованную поставку и проверенных для выбранного сценария.

  1. Администратору открыть "Чаты / Провайдеры чатов", выбрать "Добавить аккаунт" и провайдера.
  2. Ввести параметры и секреты, полученные у провайдера. Создать или подключить канал по его мастеру настройки; при необходимости настроить webhook с доступным HTTPS-адресом.
  3. Проверить, что аккаунт и канал включены, канал связан с нужной очередью, а стратегия обработки доступна.
  4. Отправить сообщение с согласованного тестового аккаунта. Проверить появление обращения и ответ оператора через "Рабочее место" или "Чаты / Диалоги".
  5. Проверить результат отправки в "Чаты / Сообщения" под администратором или супервизором. Не считать отправку успешной только потому, что текст появился в поле ввода.

Возможности вложений, статусов доставки и ответов различаются между провайдерами. Изменение условий или доступности внешнего API может влиять на соответствующий канал.

9.2. Речь и интеграции

Сервисы распознавания и синтеза речи подключаются к ядру OmniFlow и настраиваются в разделе "Речь (SpeechGate)". Стратегии используют эти возможности через интерфейсы платформы. Для Yandex SpeechKit требуются учётные данные и сетевой доступ к API провайдера. Речевой шлюз не входит в стандартную контейнерную поставку 0.68.0 и развёртывается отдельно; наличие раздела SpeechGate само по себе не включает ASR/TTS. Архитектура допускает облачные и собственные речевые сервисы через соответствующую интеграцию.

До включения проверить реквизиты, разрешения, сетевой доступ и стоимость внешнего сервиса. Транскрибация и подключение языковой модели настраиваются отдельно для выбранного сценария. При использовании внешнего API учитывать условия провайдера и требования к передаваемым данным.

Собственная стратегия разрабатывается как отдельное приложение с использованием SDK на TypeScript и взаимодействует с ядром через шину команд и событий. Встраивание коммуникационной панели и разработка стратегий выполняются по документации интегратора для соответствующей версии. Для обычного внутреннего звонка эти подключения не требуются.

10. Проверка работоспособности

После установки, изменения настроек или обновления проверить используемые каналы. Для внутренней телефонии можно использовать организацию demo и линии 701 и 702 из раздела 5 либо две доступные линии своей организации.

  1. Войти в веб-интерфейс под учётной записью своей организации с доступом к настройкам телефонии.
  2. Открыть "Телефония / Подключение и система", получить адрес сервера, порт и транспорт для телефонов.
  3. В "Телефония / SIP-пользователи" получить параметры двух линий. Пароли хранить защищённо.
  4. Настроить два телефона или софтфона. Адрес подключения - адрес сервера, логин - соответствующая линия, Domain/Realm - код организации (demo в примере). Не подставлять публичный адрес сервера вместо домена организации.
  5. Убедиться, что обе линии зарегистрированы. При отказе проверить реквизиты, домен и сеть.
  6. Позвонить с одной линии на другую, ответить и проверить звук в обе стороны непосредственно на устройствах.
  7. Завершить разговор и открыть "История звонков". Проверить участников, время и таймлайн. Если запись включена, после её обработки проверить воспроизведение и скачивание.

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

10.1. Подключённые каналы и сценарии

Дополнительно проверить функции, используемые в вашей установке:

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

11. Текущая эксплуатация

Разделы 11-13 предназначены для администратора серверной установки. При облачном использовании обслуживание выполняет поставщик; пользователям не требуется доступ к серверу. Команды остановки и перезапуска могут затронуть все организации этой установки.

cd /app/omniflow
./omniflow-ctl ps
./omniflow-ctl verify
./omniflow-ctl doctor
./omniflow-ctl logs core-node --tail 100

ps показывает состояние юнитов, verify выполняет краткую проверку, doctor выдаёт подробную диагностику. Последняя команда не является исключительно чтением: утилита синхронизирует файлы поставки. Просматривать изменения конфигурации и файлы *.dist до применения.

Контролировать свободное место, память, сертификаты, состояние линий и транков, хранилищ и резервных копий. В новой раскладке команды docker compose применяются только с явным файлом нужного юнита либо из его каталога. Для общей установки используются omniflow-ctl up|down|restart|ps|logs.

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

Пароль пользователя менять через веб-интерфейс. Для консольной процедуры пользоваться справкой ./omniflow-ctl user set-password --help; не передавать секрет в общедоступной переписке или журнале команд. Пароль в .env используется также консолью: изменение пароля в БД не означает автоматической смены сохранённых реквизитов консольного доступа.

12. Резервирование и восстановление

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

Что сохранять Состав
Параметры и версии Корневой .env, служебная конфигурация установщика, перечень юнитов, compose-файлы, версии и digest платформы и каждой стратегии.
Базы данных Дамп основной БД и ролей; при наличии дополнительных SIP-контуров - дампы их отдельных БД.
Хранилище S3 infra/data/s3store/ на остановленных компонентах, записывающих файлы.
Промежуточные записи shared/recordings/ и другие используемые общие данные.
Юниты и стратегии config/, постоянные data/, unit.env, token.env, состав и состояние strategies-<тенант>/.
Секреты и сертификаты Сохраняются защищённо вместе с конфигурацией, необходимой для восстановления; не публикуются.

Каталоги var/ содержат пересоздаваемые данные. Файлы работающего PostgreSQL не копируются вместо логического дампа. Для дополнительных БД действует то же правило. Автоматическое резервирование не считается настроенным по факту установки.

Пример отдельного дампа основной БД и ролей из каталога установки:

umask 077
STAMP=$(date +%Y%m%d-%H%M%S)
docker compose -f infra/docker-compose.yml exec -T postgres \
  pg_dump -U postgres -Fc omniflow > "backup-$STAMP.dump"
docker compose -f infra/docker-compose.yml exec -T postgres \
  pg_dumpall -U postgres --roles-only > "roles-$STAMP.sql"
docker compose -f infra/docker-compose.yml exec -T postgres \
  pg_restore --list < "backup-$STAMP.dump"

После каждой команды проверить код завершения. При ошибке не использовать полученный файл как готовую копию. Просмотр оглавления не заменяет пробное восстановление; выгрузка ролей может содержать чувствительные сведения.

Файловые данные копировать на остановленной установке; перед остановкой завершить согласованный дамп при отсутствии новых прикладных записей. Не считать разнесённые по времени дамп и файлы согласованной копией без проверки. Хранить комплект вне исходного сервера, с ограничением доступа.

Восстановление выполняется администратором в изолированной среде:

  1. Подготовить ту же версию платформы, инфраструктуры и стратегий, что указана в копии. Не подключать реальные транки, webhook и клиентов.
  2. Восстановить конфигурацию, секреты, файлы юнитов и общие данные с правильными правами. Для PostgreSQL подготовить чистые каталоги, не удаляя исходные данные без отдельного решения.
  3. Запустить только нужные БД, без мигратора и прикладных сервисов. Для основной БД: docker compose -f infra/docker-compose.yml up -d postgres; дождаться готовности.
  4. Восстановить роли, затем основную БД подходящим формату инструментом: pg_restore для custom-дампа из примера либо psql для SQL-дампа. Проверить права и все ошибки; отдельно учесть уже существующую административную роль.
  5. Восстановить дополнительные БД и проверить согласованность состояния стратегий, очередей и файлов. Возможна повторная обработка незавершённых заданий.
  6. Запустить ./omniflow-ctl up, затем ./omniflow-ctl verify; выполнить функциональную проверку, включая историю и сохранённые записи.
  7. Возвращать рабочие подключения только после проверки и разрешения администратора.

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

13. Обновление

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

Для раскладки по юнитам:

cd /app/omniflow
./omniflow-ctl upgrade 0.68.0
./omniflow-ctl doctor
./omniflow-ctl up
./omniflow-ctl verify

После каждого шага проверить результат. При появлении *.dist сопоставить эталон с локальными правками до запуска. Проверить миграции, вход, внутренний звонок и используемые текстовые сценарии.

Стратегии имеют собственные версии и не обновляются командой обновления платформы:

./omniflow-ctl strategies list --updates
./omniflow-ctl strategies upgrade <код-стратегии> <согласованная-версия>

Угловые скобки обозначают подставляемые значения, а не буквальную команду. Проверить минимальную требуемую версию платформы и результат обновления каждой используемой стратегии.

У прежней установки с корневым docker-compose.yml без каталога infra/ другой порядок управления. Не применять к ней новые пути автоматически; использовать приложение о прежней раскладке в INSTALL.md. Переход в папки-юниты необязателен и выполняется отдельно через layout plan и layout migrate после проверки ограничений и резервирования.

При переходе с MinIO на SeaweedFS нужен перенос объектов по процедуре соответствующего выпуска, а не только смена образа. Старые данные сохранять до проверки копии. Возврат прежнего тега не отменяет миграции БД; откат требует согласованной копии и учёта изменений после её создания.

14. Типовые неисправности

Признак Проверка и действие
unauthorized, denied при загрузке Проверить пользователя Docker, авторизацию и права чтения конкретного образа.
manifest unknown Уточнить публикацию всех образов выбранного тега, включая стратегии.
Не найден compose-файл в корне Для новой раскладки использовать omniflow-ctl; отдельный compose-файл находится в каталоге юнита.
Сервис перезапускается Посмотреть журнал, обязательные параметры и ресурсы; не удалять данные ради повторного запуска.
Не открывается интерфейс Проверить включение веб-компонента в состав поставки, домен, TLS, 80/443 и состояние сервиса.
Телефон не регистрируется Проверить SBC-контур, SIP-домен, логин, пароль, транспорт и сетевые правила.
Звонок есть, звука нет Проверить внешний IP, RTP-диапазон, NAT и прохождение трафика в обе стороны.
Очередь не соединяет Проверить маршрут, расписание, стратегию, назначение и статусы операторов.
Нет новых сообщений чата Проверить аккаунт/канал, секреты, webhook или опрос, провайдера, очередь и стратегию.
Ошибка после обновления Проверить ./omniflow-ctl logs infra migrator, согласованность файлов и схемы БД. Не откатывать только образ.
Не работает ASR/TTS или диалог робота Проверить наличие отдельно развёрнутого речевого шлюза и настройки провайдеров; в стандартной поставке шлюза нет.

При обращении в поддержку передать версию, время сбоя, ожидаемое и фактическое поведение, шаги воспроизведения и обезличенные диагностические сведения. Реквизиты подключения передавать только по согласованному защищённому каналу.

Техническая поддержка: support@omniflow.ru, будние дни с 09:00 до 18:00 по московскому времени. Первоначальный ответ предоставляется в течение 24 рабочих часов; это не срок устранения любой неисправности. Условия сопровождения приведены в описании жизненного цикла и поддержки.