Запись звонков

Общее

Платформа может осуществлять запись звонков.

Необходимым условием является обработка медиа трафика сервером. Запись не может быть осуществлена, если конфигурацией настроено шлюзирование вызова без обработки медиа. Например, вызов поступил через соответствующий экземпляр SG, ESG, либо это диалог с IVR и на обрабатывающем его экземпляре B2B выключена обработка медиа для таких вызовов.

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

Если в ходе диалога было сформировано несколько записей вследствие миграции медиа-шлюза, то итоговая запись объединяется.

Запись содержит звук только абонента инициатора и вызванного абонента. Мелодия удержания, генерируемая сервером, в запись не попадает, вместо нее записывается тишина.

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

Существует возможность включить запись временно в уже происходящем диалоге (через API).

Правила записи

Запись включается или выключается в соответствии с правилами записи, применяемыми для каждого нового диалога.

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

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

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

Режимы записи

Локальная запись средствами платформы

Локальная запись - стандартный режим. Медиашлюз одновременно с осуществлением обмена медиа-трафиком между устройствами абонентов производит сохранение каждого из каналов в локальный файл.

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

Такие записи присутствуют в журнале звонков и доступны для прослушивания из приложений платформы (в соответствии с ролевой политикой), либо через API.

Внешняя запись

Одновременно с обычной записью или вместо нее каждый диалог может быть записан на внешний сервер путем осуществления специального вызова(-ов). Может быть настроен режим одновременно нескольких звонков на несколько внешних серверов. Может быть настроена запись несколькими разными режимами одновременно.

При внешней записи вопросы формирования, хранения и администрирования архива записей, а также предоставления записей пользователям выносятся за пределы платформы — в надсистему.

Внешняя запись по протоколу RFC-7866 (siprec)

Запись осуществляется путем специального вызова на внешний сервер записи по протоколу RFC-7866. Ответственность за запись и хранение, а также предоставление записей пользователям в этом случае лежит на внешней системе.

Запись включается полем 'siprec' правила записи и требует настройки подключения к серверам записи, а также некоторые другие опции.

Подробнее о настройке этого режима: Настройки 'siprec'

Внешняя запись двумя вызовами (streamed_call_rec)

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

Запись включается полем 'streamed_call_rec' правила записи и требует настройки подключения к серверам записи, а также некоторые другие опции.

Подробнее о настройке этого режима: Настройки 'streamed_call_rec'

Внешняя запись одним вызовом (mixed_call_rec)

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

Запись включается полем 'mixed_call_rec' правила записи и требует настройки подключения к серверам записи, а также некоторые другие опции.

Подробнее о настройке этого режима: Настройки 'mixed_call_rec'

Стенографирование

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

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

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

Стенографирование требует настроенного доступа к сервису распознавания текстов. Вместе с системой может быть поставлен docker-образ с системой распознавания, и запущен контейнер. Необходимо прописать доступы к нему в настройках мастер-домена.

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

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

Качество стенографирования встроенным сервисом далеко от идеального, особенно страдают места с терминами или национальные языковые особенности.

Микросервисы

Запись и ее обработка обеспечивается следующими микросервисами:

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

  • MGC - транслирует команды из управляющего слоя в медиа-шлюз, обслуживающий контекст.

  • MG - обеспечивает обмен RTP-трафиком, осуществляет локальную запись каждого потока отдельно, хранит локальные записи в течение 6 часов.

  • MIXER - достает записи с медиа-шлюза, осуществляет их микширование в соответствии с настройками в конфигурации, размещает запись в общем каталоге (NFS или локально). Экземпляров микшера может быть несколько, они конкурируют за задания.

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

  • MWARE - производит инициацию стенографирования записи и размещения стенограммы.

Путь перемещения записи

recording_process

Описание процесса

  • Микросервис B2B обслуживает конкретный разговор и управляет его медиа-контекстом. При настройке правил записи - медиашлюзу передается команда на сохранение rtp-трафика. Если правилами включена внешняя запись (SIPREC), то одновременно с началом разговора производится вызов настроенных SRS по RFC7866 и трансляцией стримов обоих участвующих в разговоре абонентов.

  • Активный текущий медиагейт – микросервис MG – пишет к себе локально в каталог rectemp (конфигурация сервера). Канальные записи хранятся там не более 6 часов.

  • Инициализация микшера на подготовку записи производится событием mixer.task через брокер (микросервис BROKER) - генерируется либо с B2B, либо с CallStore (если сервис B2B упал).

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

  • Микшер создает задание и кладет его в свою рабочую папку (параметр cachefolder).

  • Асинхронный обработчик (очередь) микшера обрабатывает задания и достает по разговору из задания поканальные записи со всех медиагейтов (несколько медиагейтов, если была миграция в ходе разговора). Размещает к себе в рабочую папку, удаляет с медиагейта из папки rectemp.

  • Микшер приводит записи в единый формат, выравнивает, наполняет тишиной пропуски, микширует и сцепляет (если несколько) - все согласно таймштампам в канальных записях ртп. В результате в рабочем каталоге этого микросервиса появляется результирующий файл (mp3 или wav). Это производится в процессе с пониженным приоритетом.

  • В продолжение процесса микшер применяет сервис аналитики – по записи просчитывает процент владения и перебивания.

  • Микшер корректирует задание и отдает в другую очередь – выкладывания в хранилище микшера. Пока файл лежит в рабочем каталоге конкретного микшера.

  • Асинхронный обработчик (очередь) микшера обрабатывает задания на выкладку – переносит файлы в каталог recpath (конфигурация: mixer.recstorageid → server.recstorepaths.Key → aliases.Key, соответствует docker volume). Этот каталог может быть NFS. В нем должен присутствовать сигнальный файл rshare.sign. Пока файла нет, микшер считает каталог не готовым, не замаунченным в хранилище. При этом если каталог не подключен к NFS, то запись на этом этапе хранится на единственном конкретном сервере в этом каталоге. Но также в нем должен быть сигнальный файл rshare.sign. Путь к файлу не содержит имени домена, только дата-время по минутам. Микшер логирует этапы процесса обработки.

  • После переноса файла в указанное хранилище микшер удаляет задание и артефакты из рабочего каталога, генерирует события в брокер (callevents.call_rec_links, recmover.task).

  • Микросервис RecMover является консьюмером брокера и, получая задание, обслуживает его через очередь. Файл размещенный микшером выкачивается из локальной папки recpath, которая может быть или не быть клиентом NFS. Если там файл отсутствует (система многосерверная, NFS не подключен), то производится запрос к микшерам текущего сайта. Файл либо переносится на сервер с микшером, либо копируется (конфигурационный параметр рекмувера mode). В зависимости от того был звонок внутридоменным или кросс доменным запись отправляется согласно настройкам этих доменов в соответствующие хранилища (см. Выбор хранилища домена). При этом в каталоге recpath точно также должен быть rshare.sign. Если каталог является клиентом NFS, то все операции производятся локально и фактически лежат в одном и том же хранилище в смежных подкаталогах. В режиме TRACE рекмувер печатает трейс выполнения задания. Ошибки, в том числе доступа к S3 - там. При неудаче некоторое время задание хранится в рекмувере и периодически делает попытки повторной обработки (см. Поведение при недоступности хранилищ). В конце генерируется событие callevents.records_moved, а также asr.task - задание в сторону брокера на стенографирование разговора.

  • Сервис стенографирования работает в рамках mware. В соответствии с настройками правил стенографирования - выкачивает разговор из домена осуществлявшего запись, производит его распаковку в каналы, обращается в внешнему сервису распознавания речи, результат компанует в формат текстового диалога. В конце генерирует событие callevents.call_asr

Хранение записей

Записи, осуществленные локально, проходят через несколько каталогов и в итоге размещаются в хранилищах доменов участников диалога. Постоянным местом хранения записи является хранилище домена. Все предыдущие каталоги — промежуточные.

Этап Каталог Настройка

Канальные записи на MG

RECORD (rectemp), до 6 часов

Параметр роли mg, при установке — docker-волюм на каждом сервере

Рабочий каталог микшера

По умолчанию /var/lib/era/_workdir/{NODE} в контейнере

mix.cachefolder → aliases

Общее хранилище результатов микшера

RECSTORE (recpath)

mix.recstorageid → recstorepaths → aliases

Хранилище домена

S3, смонтированный раздел NFS, либо раздел по умолчанию в RECSTORE

Сущность storage, правило записи recordrule.storagekey, насторойка домена settings.rec_storagekey_default, параметр конфигурации recmover recmover.default_recstorageid

Каталог канальных записей

Во время диалога запись производится микросервисом MG в локальную папку RECORD. По умолчанию в конфигурации для этого указывается папка, присоединенная в качестве docker-волюма к docker-контейнеру с платформой. Во время установки системы на каждый сервер инсталлятор запрашивает место размещения этой папки в хосте сервера.

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

Каталоги микшера

Микшер использует два каталога.

Рабочий каталог задается параметром cachefolder. По умолчанию это рабочий каталог ноды в разделе /var/lib/era контейнера. В нем размещаются задания, скачанные канальные записи и результаты микширования до их выкладки в общее хранилище.

Общее хранилище задается параметром recstorageid. Поскольку система многосерверная, и абсолютные пути на серверах могут различаться, каталоги для записей описываются в два уровня: алиасы путей в разделе aliases, и ключеванные разделы в параметре сервера recstorepaths.

mix.recstorageid ──► servers[].recstorepaths[key] ──► aliases.paths[alias] ──► путь в контейнере
Микшер размещает результаты в общем хранилище только при наличии в каталоге сигнального файла rshare.sign. Файл размещается инсталлятором при установке. При подготовке нового каталога его необходимо скопировать вручную.

Хранилища доменов

Хранилища доменов — сущности storage, типизированные параметры подключения. Из файловых типов для хранения записей разговоров применимы два:

  • s3 — внешнее объектное хранилище S3;

  • nfs — каталог, путь к которому единым образом определен для всех контейнеров на всех серверах. Как правило — примонтированный сетевой раздел, но каталог может быть и локальным.

Типы fs и fsync для хранения записей разговоров не предназначены.

Выбор хранилища домена

Recmover размещает запись в каждом домене, запросившем запись, следующим образом:

  1. Используется хранилище, код (instance) которого указан в поле storagekey правила записи, примененного доменом и включившего запись.

  2. Если поле не заполнено, используется код каталога записи из параметра домена settings.rec_storagekey_default, а если не задан и он — в разделе по умолчанию.

  3. Если хранилище с таким кодом в домене в этот момент отсутствует или имеет неподходящий тип, запись размещается в разделе по умолчанию, то есть в том разделе, куда запись разместил микшер, однако в подкаталоге домена domain/{DOMAIN}.

Раздел по умолчанию определяется так:

  • начиная с версии 1.11.1 — параметром recmover default_recstorageid, по цепочке recmover.default_recstorageid → servers[].recstorepaths → aliases.paths;

  • если default_recstorageid не задан или пуст (и во всех версиях до 1.11.1) — тем же разделом, в который разместил запись микшер (recstorageid микшера).

Из общего хранилища микшера запись после переноса удаляется, либо остается там, в зависимости от параметра mode роли recmover.

Схема по умолчанию

При установке через инсталлятор с параметрами по умолчанию платформа не использует сетевых хранилищ:

  • в контейнере каталог /var/lib/era_files/recpath подключен как волюм к каталогу хоста (по умолчанию /opt/era/era_recpath);

  • экземпляры микшера в конфигурациях, созданных мастером конфигураций, указывают на этот раздел;

  • правила записи не указывают хранилище, поэтому recmover размещает записи доменов в том же разделе, в подкаталоге домена.

В односерверной конфигурации все записи оказываются на диске сервера.

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

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

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

Использование примонтированного раздела

Для централизованного хранения каталог recpath может быть подключен к сетевому хранилищу — NFS, virtiofs и подобным. Тогда все серверы видят единый каталог, а архив не зависит от дисков отдельных серверов.

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

  1. микшер записывает файл в сетевой раздел;

  2. recmover читает его из сетевого раздела и записывает копию в хранилище домена в том же сетевом разделе;

  3. recmover удаляет исходный файл в сетевом разделе.

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

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

Локальный раздел для результатов микшера

Целевая схема при использовании сетевого хранилища:

  • микшер размещает результаты на локальном разделе сервера;

  • хранилища доменов располагаются в сетевом разделе, либо во внешнем S3 (см. Рекомендуемое решение: архив в S3).

В этом случае через сетевой интерфейс проходит только одна операция — запись итогового файла в хранилище домена. Удаление исходного файла и обслуживание общего хранилища микшера выполняются на локальном диске.

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

В примерах используются условные значения:

Значение Назначение

main / recpath

Прежние ключ раздела и алиас пути к примонтированному разделу. Не изменяются.

mixlocal / mixrec

Новые ключ раздела и алиас пути к локальному каталогу микшера.

recnfs

Код хранилища типа nfs в домене.

Шаг 1. Сохранить размещение записей доменов

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

Вариант А, с версии 1.11.1. Задать у экземпляров recmover параметр default_recstorageid равным прежнему ключу:

{
  "roletype": "recmover",
  "default_recstorageid": "main"
}

Настройка доменов в этом случае не требуется.

Вариант Б. В каждом домене, где ведется запись, создать хранилище типа nfs, ссылающееся на прежний ключ раздела:

{
  "type": "nfs",
  "instance": "recnfs",
  "params": {
    "configkey": "rec:main",
    "prefix": "domain"
  }
}

где configkey имеет вид rec:<KEY> (<KEY> — прежний recstorageid микшера), а prefix — подкаталог, в котором recmover размещал записи доменов.

Затем указать "storagekey": "recnfs" в правилах записи домена, включающих запись (rec = 1), либо задать recnfs в параметре домена rec_storagekey_default.

Шаг 2. Подготовить локальный каталог

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

Создайте каталог и поместите в него rshare.sign:

mkdir -p <HOST_SITESHARE>/mixrec
touch <HOST_SITESHARE>/mixrec/rshare.sign
Проверьте, что выбранный каталог действительно не расположен на сетевом разделе. Фактический путь siteshare задается параметром сервера sitesharepath.

Шаг 3. Изменить конфигурацию

Добавить алиас локального каталога в aliases.paths
{ "alias": "mixrec", "value": "/var/lib/era_files/siteshare/mixrec" }
Добавить ключ в recstorepaths каждого сервера с микшером (прежний ключ сохраняется)
"recstorepaths": [
  { "key": "main",     "value": "alias://paths/recpath" },
  { "key": "mixlocal", "value": "alias://paths/mixrec" }
]
Указать новый ключ у каждого экземпляра микшера
{
  "roletype": "mix",
  "recstorageid": "mixlocal"
}

Активируйте конфигурацию.

Шаг 4. Проверить

  1. Совершите тестовый звонок с записью.

  2. Убедитесь, что файл кратковременно появляется в локальном каталоге микшера и исчезает после обработки recmover-ом.

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

  4. Проверьте доступность ранее сделанных записей.

Поведение при недоступности хранилищ

Микшер. Если общее хранилище недоступно или в нем отсутствует сигнальный файл rshare.sign, микшер не выкладывает записи, но продолжает забирать канальные записи с MG и микшировать их. Результаты накапливаются в рабочем каталоге (cachefolder). Поскольку на MG канальные записи хранятся не более 6 часов, такое поведение позволяет сохранить записи на более долгий период — до восстановления хранилища. Размер рабочего каталога при этом растет; экземпляров микшера может быть несколько, и каждый накапливает свою часть записей.

При выборе раздела для cachefolder учитывайте ожидаемое время недоступности хранилища. Для оценки: при формате mp3 с битрейтом 24 кбит/с минута записи занимает около 180 КБ, час разговоров — около 11 МБ. По умолчанию рабочий каталог расположен в разделе /var/lib/era контейнера.

Recmover. При недоступности хранилища recmover сохраняет задания и периодически повторяет попытки: до 100 тысяч записей в течение 24 часов. По истечении этого времени задание удаляется. Активный экземпляр recmover на сайте один.

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

Примонтированные разделы. При недоступности NFS-сервера процессы, обращающиеся к примонтированному разделу, замирают до его восстановления.

В версиях до 1.10.7 охват блокировки при недоступности NFS-сервера мог быть шире: в зависимость от сетевого раздела попадала работа с файловой системой в целом, что могло блокировать работу платформы.

Требования к сетевому файловому хранилищу

Если архив записей размещается в сетевом файловом хранилище, оно становится критичным компонентом:

  • хранилище должно быть отказоустойчивым (в идеале — HA-решение);

  • хранилище должно администрироваться обособленно от платформы: резервное копирование, контроль объема, очистка устаревших записей.

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

Рекомендуемое решение: архив в S3

Наиболее надежный и рекомендуемый способ хранения архива записей — внешнее хранилище S3.

  1. В домене создается хранилище типа s3:

    {
  "type": "s3",
  "instance": "records_s3",
  "params": {
    "endpoint": "https://s3.example.ru",
    "bucket": "call-records",
    "prefix": "domain1/",
    "keyId": "...",
    "secretKey": "..."
  }
}

  2. Код хранилища указывается в поле storagekey правил записи домена, либо в параметре домена rec_storagekey_default.

В этом случае:

  • архив записей выведен за пределы платформы и администрируется отдельно, как и должно быть;

  • доступ к архиву не зависит от примонтированных разделов в файловой системе серверов;

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

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

Итоговые рекомендации

Ситуация Рекомендация

Односерверная установка, умеренный объем записей

Схема по умолчанию. Контролировать место на диске.

Требуется централизованный архив

Хранилище S3 в доменах; общее хранилище микшера — на локальном разделе.

Используется NFS или иной примонтированный раздел

Разделить каталоги: микшер на локальном разделе, хранилища доменов в сетевом. Обеспечить HA и обособленное администрирование хранилища.

Запись и архив ведутся внешней системой

Внешняя запись, например SIPREC.

Доступ к записям для прослушивания

Прослушивание записей средствами платформы (через API или из приложений платформы) возможно только в том случае, если запись производилась в локальном режиме.

Доступ к записям определяется ролевой политикой.

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

В особых случаях может быть настроен доступ по постоянным ссылкам в авторизованном подключении с доступом к соответствующим эндпойнтам:

  • используя эндпойнт xref:api:api/admin/callrecords.adoc, параметризуемый непосредственно адресом записи в хранилище.

  • через включение опции сохранения информации о звонках и записях в отдельную архивную коллекцию и доступом к вложениям.

Запись конференций

Конференция - это отдельный user-agent, имеющий собственный медиа-контекст. Каждый участник подключен к медиа-контексту конференции через диалог, имеющий собственный медиа-контекст в рамках звонка.

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

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

  • В конференцию в любой момент можно добавить произвольное количество технических участников - рекордеров, и установить для них необходимую топологию. Например, это могут быть вызовы из IVR с компонентом "Запись". В этом случае размещение и доступ к этой записи - ответственность сценария и надсистемы.

  • Персонализация
  • Увеличить шрифт
  • Уменьшить шрифт