Запись звонков
Общее
Платформа может осуществлять запись звонков.
Необходимым условием является обработка медиа трафика сервером. Запись не может быть осуществлена, если конфигурацией настроено шлюзирование вызова без обработки медиа. Например, вызов поступил через соответствующий экземпляр 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 - перемещает запись в хранилища доменов, абоненты которых участвовали в диалоге, и правила которых включили запись.
-
MWARE - производит инициацию стенографирования записи и размещения стенограммы.
Место хранения записей
Записи, осуществленные локально, после переноса их в домены участников диалога, хранятся в доменных хранилищах.
Варианты:
-
NFS-папка, присоединенная к NFS-серверу и подключенная в качестве волюма в контейнер системы. При инсталляции в эту папку размещается файл 'rshare.sign', указывающий на доступность сервера.
-
При тех же условиях, если папка не является подключенной к NFS, то размещается локально на сервере с ролью recmover. При обращении к файлу перебираются все серверы, где активны экземпляры микросервиса recmover.
-
в S3 хранилище (если для такового в домене создано и настроено хранилище, и в правиле записи указан его код из поля 'instance').
Во время диалога запись производится микросервисом MG в локальную папку RECORD. По умолчанию в конфигурации для этого указывается папка, присоединенная в качестве docker-волюма к docker-контейнеру с платформой. Во время установки системы на каждый сервер инсталлятор запрашивает место размещения этой папки в хосте сервера. Рекомендуется, чтобы эта папка размещалась на диске, не имеющем риска образовать очередь доступа на запись. Несмотря на то, что складывание данных в файл ведется асинхронно, само открытие файла - процедура синхронная и строго ограниченная во времени. При таймауте в несколько секунд - разговор не состоится.
Микшер копирует файл с MG к себе в рабочий каталог ("/var/lib/era" внутри контейнера), и там же производит микширование. После операции микширования файл переносится (копируется и удаляется) в каталог RECSTORE в общий раздел.
После разнесения по доменам файл записи либо выносится во внешнее хранилище домена, либо копируется в раздел домена того же каталога RECSTORE. При соответствующей настройке свойств экземпляра в конфигурации, запись из общего раздела может либо быть удалена или оставлена там.
Доступ к записям для прослушивания
Прослушивание записей средствами платформы (через API или из приложений платформы) возможно только в том случае, если запись производилась в локальном режиме.
Доступ к записям определяется ролевой политикой.
Для доступа к файлу всегда формируется временная ссылка со сложным уникальным именем, доступная публично в течение 5 минут.
Запись конференций
Конференция - это отдельный user-agent, имеющий собственный медиа-контекст. Каждый участник подключен к медиа-контексту конференции через диалог, имеющий собственный медиа-контекст в рамках звонка.
Как и другие медиа-контексты, конференц-контекст имеет функцию записи, однако она недоступна пользователю. В сложных топологиях конференции не существует однозначно правильного состава участников для формирования единственного файла записи. Поэтому платформа не записывает медиа-контекст конференции, предполагая, что запись ведется в надсистемах:
-
Каждый участник должен иметь возможность прослушать ровно тот участок и состав конференции, в котором он участвовал и имел возможность слушать. Поэтому может вестись запись разговора абонента с конференцией. Это управляется стандартными правилами записи. При возможности доступа абонента к записям своих разговоров ему будет доступна и запись конференции (то есть своего разговора с участниками конференции).
-
В конференцию в любой момент можно добавить произвольное количество технических участников - рекордеров, и установить для них необходимую топологию. Например это могут быть вызовы из IVR с компонентом "Запись". В этом случае размещение и доступ к этой записи - ответственность сценария и надсистемы.
Путь перемещения записи
Описание процесса
-
Микросервис B2B обслуживает конкретный разговор и управляет его медиа-контекстом. При настройке правил записи - медиашлюзу передается команда на сохранение rtp-трафика. Если правилами включена внешняя запись (SIPREC), то одновременно с началом разговора производится вызов настроенных SRS по RFC7866 и трансляцией стримов обоих участвующих в разговоре абонентов.
-
Активный текущий медиагейт – микросервис MG – пишет к себе локально в каталог rectemp (конфигурация сервера).
-
Инициализация микшера на подготовку записи производится событием mixer.task через брокер (микросервис BROKER) - генерируется либо с B2B, либо с CallStore (если сервис B2B упал).
-
Микшеры – это микросервисы, консьюмеры брокера – конкурируют за задания, не выходя за установленные в конфигурации пределы параллельной загруженности.
-
Микшер создает задание и кладет его в свою рабочую папку.
-
Асинхронный обработчик (очередь) микшера обрабатывает задания и достает по разговору из задания поканальные записи со всех медиагейтов (несколько медиагейтов, если была миграция в ходе разговора). Размещает к себе в рабочую папку, удаляет с медиагейта из папки 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). В зависимости от того был звонок внутридоменным или кросс доменным запись отправляется согласно настройкам этих доменов в соответствующие хранилища. Либо S3 конкретного домена, либо в рамках recpath переносится в подкаталог с именем домена. При этом в каталоге recpath точно также должен быть rshare.sign. Если каталог является клиентом NFS, то все операции производятся локально и фактически лежат в одном и том же хранилище в смежных подкаталогах. В режиме TRACE рекмувер печатает трейс выполнения задания. Ошибки, в том числе доступа к S3 - там. При неудаче некоторое время задание хранится в рекмувере и периодически делает попытки повторной обработки. Через некоторое время неудач задание автоматически удаляется. В конце генерируется событие callevents.records_moved, а также asr.task - задание в сторону брокера на стенографирование разговора.
-
Сервис стенографирования работает в рамках mware. В соответствии с настройками правил стенографирования - выкачивает разговор из домена осуществлявшего запись, производит его распаковку в каналы, обращается в внешнему сервису распознавания речи, результат компанует в формат текстового диалога. В конце генерирует событие callevents.call_asr