Как использовать интерфейс потока RTSP в VIGI NVR OpenAPI

Руководство по настройке

Последнее обновление:августа 31, 2026

Содержание

Введение

Требования

Настройка

Проверка конфигурации RTSP NVR

Доступ к потокам Live View и Playback через RTSP

Процесс передачи аудио Talk

Заключение

Вопросы и ответы

Введение

OpenAPI VIGI NVR предоставляет интерфейс потоков на основе RTSP для Live View, Playback и передачи аудио Talk. Live View и Playback позволяют клиентам получать потоки живого или записанного аудио и видео, в то время как функция Talk позволяет передавать звук с микрофона на выбранный канал камеры.

Эти функции используют RTSP для установки и управления сеансами, Digest Authentication для проверки доступа и RTP для передачи медиаданных. Для Live View и Playback RTP может передаваться по TCP или UDP в зависимости от режима транспорта, согласованного в процессе RTSP SETUP. В описанном в этой статье процессе Talk звук с микрофона передается через отдельный сеанс Talk по выделенному TCP-соединению.

Требования

VIGI NVR с поддержкой OpenAPI. (Для проверки поддерживаемых моделей обратитесь к Устройства, поддерживаемые VIGI Open API)
Документация OpenAPI VIGI NVR
RTSP-клиент или сторонняя платформа с сетевым доступом к NVR

Настройка

Проверка конфигурации RTSP NVR

Интерфейс потоков OpenAPI VIGI NVR реализован на основе RTSP. RTSP включен по умолчанию на VIGI NVR, а порт RTSP по умолчанию — 554. Перед доступом к потокам Live View или Playback или установкой сеанса Talk убедитесь, что RTSP включен, и проверьте настроенный порт RTSP.

В следующей процедуре в качестве примера используется веб-страница управления NVR.

Шаг 1. Войдите в веб-интерфейс NVR, используя его IP-адрес. Введите имя пользователя и пароль, затем нажмите Войти.

Страница входа в NVR с полями IP-адреса, имени пользователя, пароля и кнопкой входа.

Шаг 2. Перейдите в Настройки > Сеть > Сетевые службы > RTSP(S). Убедитесь, что переключатель RTSP включен, и обратите внимание на настроенный RTSP-порт.

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

Веб-интерфейс VIGI NVR с включенным RTSP на порту 554 и отключенными RTSPS и SRTP.

Доступ к потокам Live View и Playback через RTSP

Интерфейсы Live View и Playback VIGI NVR используют стандартный RTSP для установки сеансов и управления ими, а RTP передает аудио- и видеоданные. Стандартные RTSP-клиенты или сторонние платформы могут получить доступ к потокам, используя соответствующий URL и выполняя аутентификацию RTSP и настройку сеанса.

Следующий процесс использует Live View в качестве примера, поскольку Live View и Playback следуют одному и тому же общему процессу. Для Playback используйте соответствующий URL воспроизведения и временной диапазон. Поддерживаемые методы, форматы URL, параметры и Digest Authentication см. в разделах 5.1–5.3 документа VIGI NVR OpenAPI Document и вопрос 2 в разделе «Вопросы и ответы» этой статьи.

Шаг 1. Установите RTSP-соединение и запросите поддерживаемые методы.

Клиент сначала устанавливает TCP-соединение с NVR через настроенный порт RTSP, который по умолчанию равен 554. Шаги следующие:

(1) Клиент отправляет первоначальный неаутентифицированный запрос OPTIONS для запроса методов RTSP, поддерживаемых NVR.

/* Запрос без аутентификации */

C->S :

OPTIONS rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n

CSeq: 1\r\n

User-Agent: VIGI-RTSP-Player/1.0\r\n

\r\n

(2) NVR возвращает 200 OK и перечисляет поддерживаемые методы RTSP в заголовке Public.

S->C :

RTSP/1.0 200 OK\r\n

CSeq: 1\r\n

Date: Mon, 20 Jul 2026 21:57:33 GMT\r\n

User-Agent: vigi\r\n

Public: DESCRIBE,SETUP,TEARDOWN,PLAY,PAUSE,GET_PARAMETER,SET_PARAMETER\r\n

Content-Length: 0\r\n

\r\n

На следующем захвате Wireshark показан первоначальный запрос OPTIONS и соответствующий ответ 200 OK от NVR.

Запрос OPTIONS RTSP VIGI NVR и ответ 200 OK со списком поддерживаемых методов RTSP.

Шаг 2. Запросите описание мультимедиа и завершите Digest Authentication.

Клиент отправляет неаутентифицированный запрос DESCRIBE для получения описания мультимедиа запрашиваемого потока. Поскольку запрос не содержит информации об аутентификации, NVR отвечает кодом 401 Unauthorized и предоставляет вызов Digest-аутентификации в заголовке WWW-Authenticate.

(1) Клиент отправляет неаутентифицированный запрос DESCRIBE для получения описания мультимедиа SDP.

/* Запрос без аутентификации */

C->S :

DESCRIBE rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n

CSeq: 2\r\n

User-Agent: VIGI-RTSP-Player/1.0\r\n

Accept: application/sdp\r\n

\r\n

(2) NVR возвращает 401 Unauthorized и предоставляет вызов Digest-аутентификации в заголовке WWW-Authenticate.

S->C:\r\n

RTSP/1.0 401 Unauthorized\r\n

CSeq: 2\r\n

User-Agent: vigi\r\n

WWW-Authenticate: Digest realm="vigi", nonce="668a48d0", stale="FALSE"\r\n

Content-Length: 0\r\n

\r\n

Примечание: Ответ 401 Unauthorized является ожидаемой частью процесса Digest-аутентификации и не указывает на окончательную ошибку аутентификации.

(3) Клиент получает realm и nonce из заголовка WWW-Authenticate и использует их вместе с именем пользователя, паролем, текущим методом RTSP и URI запроса для вычисления Digest-ответа. Затем он повторно отправляет запрос DESCRIBE с заголовком Authorization.

Например:

Метод: DESCRIBE

URI запроса: rtsp://192.168.0.110:554/live/1/2/avm

Алгоритм Digest должен соответствовать алгоритму аутентификации, настроенному на NVR.

В этом примере NVR настроен на использование MD5.

HA1 = MD5(имя_пользователя:realm:пароль)

HA2 = MD5(метод:request-uri)

response = MD5(HA1:nonce:HA2)

Примечание: Проверьте алгоритм аутентификации в разделе Настройки > Сеть > Сетевые службы > RTSP(S). Клиент должен использовать тот же алгоритм при вычислении Digest-ответа.

Страница настроек RTSP VIGI NVR с конфигурацией аутентификации MD5.

Клиент повторно отправляет запрос DESCRIBE с учетными данными Digest, включенными в заголовок Authorization.

C->S :

DESCRIBE rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n

CSeq: 3\r\n

User-Agent: VIGI-RTSP-Player/1.0\r\n

Accept: application/sdp\r\n

Authorization: Digest username="admin", realm="vigi", nonce="668a48d0", uri="rtsp://192.168.0.110:554/live/1/2/avm", response="<вычисленный_digest_ответ>"\r\n

\r\n

(4) NVR проверяет Digest-ответ. Если аутентификация успешна, он возвращает 200 OK вместе с описанием мультимедиа SDP.

Ответ SDP описывает доступные медиа-потоки и их кодеки. В этом примере поток track1 содержит видео H.264, а track2 — аудио PCMA.
Примечание: track3 содержит данные, определенные собственным протоколом VIGI, и не требуется для стандартной потоковой передачи видео и аудио.

S->C :

RTSP/1.0 200 OK\r\n

CSeq: 3\r\n

Date: Mon, 20 Jul 2026 19:01:11 GMT\r\n

Content-Type: application/sdp\r\n

Content-Length: 395\r\n

\r\n

<SDP>

v=0\r\n

s=Session streamed by "TP-Link RTSP Server"\r\n

t=0 0\r\n

m=video 0 RTP/AVP 96\r\n

a=control:track1\r\n

a=rtpmap:96 H264/90000\r\n

a=fmtp:96 packetization-mode=1; profile-level-id=4D4032; sprop-parameter-sets=Z00AKpY1QPAET8s3AQEBQAABwgAAV+QB,aO48gA==\r\n

m=audio 0 RTP/AVP 8\r\n

a=control:track2\r\n

a=rtpmap:8 PCMA/8000\r\n

m=application/TP-LINK 0 RTP/AVP smart/0/25000\r\n

a=control:track3\r\n

a=rtpmap:95 TP-LINK/25000\r\n

Захват Wireshark с обменом Digest-аутентификации RTSP и ответом SDP от VIGI NVR.

Шаг 3. Настройте медиа-потоки и запустите передачу RTP.

После успешной аутентификации клиент настраивает требуемые медиа-потоки и согласовывает режим транспорта. Поддерживаются как RTP через UDP, так и RTP через RTSP/TCP. В этом примере используется RTP через RTSP/TCP с чередующимся транспортом.

(1) Клиент отправляет отдельные запросы SETUP для требуемых видеопотока и аудиопотока и указывает режим транспорта для каждого потока. NVR возвращает 200 OK на каждый запрос. В этом примере оба потока используют один и тот же идентификатор сеанса RTSP, и клиент запрашивает RTP через RTSP/TCP. Чередующиеся каналы 0 и 1 назначаются видеопотокам RTP и RTCP, а каналы 2 и 3 — аудиопотокам RTP и RTCP.

C->S:\r\n

SETUP rtsp://192.168.0.110:554/live/1/2/avm/track1 RTSP/1.0\r\n

CSeq: 4\r\n

User-Agent: VIGI-RTSP-Player/1.0\r\n

Transport: RTP/AVP/TCP;unicast;interleaved=0-1\r\n

Authorization: Digest username="admin", realm="vigi", nonce="668a48d0", uri="rtsp://192.168.0.110:554/live/1/2/avm/track1", response="<вычисленный_digest_ответ>"\r\n

\r\n

S->C:\r\n

RTSP/1.0 200 OK\r\n

CSeq: 4\r\n

User-Agent: vigi\r\n

Session: 0x7fb484;timeout=60\r\n

Transport: RTP/AVP/TCP;interleaved=0-1\r\n

Content-Length: 0\r\n

\r\n

C->S:\r\n

SETUP rtsp://192.168.0.110:554/live/1/2/avm/track2 RTSP/1.0\r\n

CSeq: 5\r\n

Session: 0x7fb484\r\n

User-Agent: VIGI-RTSP-Player/1.0\r\n

Transport: RTP/AVP/TCP;unicast;interleaved=2-3\r\n

Authorization: Digest username="admin", realm="vigi", nonce="668a48d0", uri="rtsp://192.168.0.110:554/live/1/2/avm/track2", response="<вычисленный_digest_ответ>"\r\n

\r\n

S->C:\r\n

RTSP/1.0 200 OK\r\n

CSeq: 5\r\n

User-Agent: vigi\r\n

Session: 0x7fb484;timeout=60\r\n

Transport: RTP/AVP/TCP;interleaved=2-3\r\n

Content-Length: 0\r\n

\r\n

Захват Wireshark с запросами RTSP SETUP и PLAY с чередующимися каналами RTP через TCP.

Примечание: В чередующемся транспорте RTSP пакеты RTP и RTCP для нескольких медиа-потоков используют одно TCP-соединение и различаются по номерам чередующихся каналов.

(2) Клиент отправляет запрос PLAY с идентификатором сеанса для запуска передачи мультимедиа.

C->S:\r\n

PLAY rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n

CSeq: 6\r\n

Session: 0x7fb484\r\n

User-Agent: VIGI-RTSP-Player/1.0\r\n

Authorization: Digest username="admin", realm="vigi", nonce="668a48d0", uri="rtsp://192.168.0.110:554/live/1/2/avm", response="<вычисленный_digest_ответ>"\r\n

\r\n

(3) NVR возвращает 200 OK и начинает передачу пакетов RTP по установленному TCP-соединению RTSP.
Примечание: В режиме просмотра Follow TCP Stream в Wireshark чередующиеся данные RTP отображаются как двоичное содержимое после ответа RTSP.

S->C:\r\n

RTSP/1.0 200 OK\r\n

CSeq: 6\r\n

Date: Mon, 20 Jul 2026 21:57:33 GMT\r\n

User-Agent: vigi\r\n

Session: 0x7fb484;timeout=60\r\n

RTP-Info: url=rtsp://192.168.0.110:554/live/1/2/avm;seq=34976;rtptime=2315908260\r\n

Content-Length: 0\r\n

\r\n

Захват Wireshark с ответом RTSP PLAY и чередующимися медиаданными RTP/RTCP через TCP от VIGI NVR.

После принятия запроса PLAY клиент непрерывно получает пакеты RTP через согласованный транспорт. В этом примере медиа-пакеты передаются по установленному TCP-соединению RTSP с использованием чередующегося транспорта.

Шаг 4. Разбор и декодирование пакетов RTP.

После получения пакетов RTP клиент анализирует и декодирует их для отображения живого видео и воспроизведения соответствующего аудио. Шаги следующие:

(1) Разбор заголовка пакета RTP.

Клиент считывает такие поля, как порядковый номер, временная метка, маркерный бит и тип полезной нагрузки (Payload Type). Порядковый номер используется для обнаружения порядка пакетов и потери пакетов, а временная метка используется для синхронизации мультимедиа. Тип полезной нагрузки используется вместе с атрибутами SDP a=rtpmap для идентификации соответствующего кодека и тактовой частоты.

Для значений типа полезной нагрузки, определенных или рекомендованных для потоков VIGI NVR, обратитесь к Приложению II, Payload Type, в документе VIGI NVR OpenAPI Document. Динамические типы полезной нагрузки могут различаться, поэтому информация SDP, возвращаемая NVR, должна использоваться в качестве основного источника.

В этом примере:

a=rtpmap:96 H264/90000

a=rtpmap:8 PCMA/8000

Тип полезной нагрузки 96 передает видео H.264, а тип полезной нагрузки 8 передает аудио PCMA.

(2) Обработка полезной нагрузки RTP.

Клиент удаляет заголовок RTP и извлекает закодированную медиа-полезную нагрузку. Для видео H.264 клиент восстанавливает полные NAL-блоки из полезной нагрузки RTP, включая фрагментированные или агрегированные NAL-блоки при необходимости. Для аудио PCMA клиент извлекает образцы аудио G.711 A-law из полезной нагрузки RTP.

(3) Декодирование и визуализация мультимедиа.
Клиент передает восстановленные видео- и аудиоданные соответствующим декодерам. Медиа-библиотека, такая как FFmpeg, может декодировать видео H.264 в последовательность кадров и преобразовывать аудио PCMA в воспроизводимые PCM-сэмплы. Затем клиент отображает видеокадры и выводит аудио через устройство воспроизведения.

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

Процесс передачи аудио Talk

Как описано в разделе Доступ к потокам Live View и Playback через RTSP, клиент получает видео и аудио от NVR через сеанс Live View. В этом разделе описывается процесс Talk, в котором клиент захватывает звук с микрофона и передает его на NVR или на камеру, управляемую NVR, для вывода через динамик.

Функция Talk использует расширение RTSP, специфичное для VIGI. Клиент должен установить отдельный сеанс Talk и передавать аудио в соответствии с требуемыми командами сеанса, форматом аудио и правилами инкапсуляции RTP.

Шаг 1. Установите отдельное RTSP-соединение для Talk.

Клиент устанавливает отдельное TCP-соединение с NVR через настроенный порт RTSP. Это соединение предназначено для передачи аудио Talk и не зависит от сеанса Live View. Затем клиент отправляет первоначальный неаутентифицированный запрос MULTITRANS по URI /multitrans.

Примечание: MULTITRANS — это проприетарное расширение RTSP, реализованное VIGI NVR, и оно может не отображаться в заголовке Public, возвращаемом стандартным сеансом RTSP.

C->S:\r\n

MULTITRANS rtsp://192.168.0.110:554/multitrans RTSP/1.0\r\n

CSeq: 1\r\n

User-Agent: VIGI-Python-Talk/1.0\r\n

Content-Type: application/json\r\n

Content-Length: 0\r\n

\r\n

Follow TCP Stream в Wireshark с неаутентифицированным запросом MULTITRANS по отдельному Talk-соединению RTSP.

Шаг 2. Завершение Digest Authentication.

Первоначальный запрос MULTITRANS не содержит информации об аутентификации. Поэтому NVR возвращает 401 Unauthorized вместе с вызовом Digest-аутентификации. Клиент вычисляет Digest-ответ, как описано в предыдущем разделе, и повторно отправляет запрос MULTITRANS с заголовком Authorization.

S->C:\r\n

RTSP/1.0 401 Unauthorized\r\n

CSeq: 1\r\n

Date Mon, 27 Jul 2026 22:42:08 GMT \r\n

User-Agent: vigi\r\n

WWW-Authenticate: Digest realm="vigi", nonce=" f62dd168 ", stale="FALSE"\r\n

Content-Length: 0\r\n

\r\n

C->S:\r\n

MULTITRANS rtsp://192.168.0.110:554/multitrans RTSP/1.0\r\n

CSeq: 2\r\n

User-Agent: VIGI-Python-Talk/1.0\r\n

Content-Type: application/json\r\n

Content-Length: 0\r\n

Authorization: Digest username="admin", realm="vigi", nonce="6061d988", uri="rtsp://192.168.0.110:554/multitrans", response="<вычисленный_digest_ответ>"\r\n

\r\n

Follow TCP Stream в Wireshark с вызовом Digest 401 с последующим аутентифицированным запросом MULTITRANS.

Шаг 3. Создание сеанса Talk.

После принятия аутентифицированного запроса MULTITRANS NVR возвращает 200 OK и создает выделенный RTSP-сеанс для Talk-соединения. Ответ включает значение сеанса RTSP и JSON-идентификатор session_id. Клиент должен сохранить эти значения и использовать их по мере необходимости для последующих взаимодействий Talk.

S->C:\r\n

RTSP/1.0 200 OK\r\n

CSeq: 2\r\n

Date: Mon, 27 Jul 2026 22:42:08 GMT \r\n

User-Agent: vigi\r\n

Session: 0x822e60\r\n

Content-Type: application/json\r\n

Content-Length: 80\r\n

\r\n

{"type":"response","seq":2,"params":{"error_code":0,"session_id":"14684328"}}

Значение error_code, равное 0, указывает на успешное создание сеанса Talk.

Follow TCP Stream в Wireshark с ответом 200 OK и идентификатором сеанса RTSP и успешным идентификатором сеанса Talk.

Шаг 4. Отправка команды Talk.

После создания сеанса Talk клиент отправляет другой аутентифицированный запрос MULTITRANS, содержащий JSON-команду talk. Команда указывает режим Talk и целевой канал NVR, на динамик камеры которого будет воспроизводиться загруженное аудио.

C->S:\r\n

MULTITRANS rtsp://192.168.0.110:554/multitrans RTSP/1.0\r\n

CSeq: 3\r\n

User-Agent: VIGI-Python-Talk/1.0\r\n

Content-Type: application/json\r\n

Content-Length: 93\r\n

Session 0x822e60\r\n

Authorization: Digest username="admin", realm="vigi", nonce="6061d988", uri="rtsp://192.168.0.110:554/multitrans", response="<вычисленный_digest_ответ>"\r\n

\r\n

{"type":"request","seq":1,"params":{"method":"do","talk":{"mode":"half_duplex","channel":1}}}

S->C:\r\n

RTSP/1.0 200 OK\r\n

CSeq: 3\r\n

Date: Mon, 27 Jul 2026 22:42:08 GMT\r\n

User-Agent: vigi\r\n

Session: 0x822e60\r\n

Content-Type: application/json\r\n

Content-Length: 80\r\n

\r\n

{"type":"response","seq":3,"params":{"error_code":0,"session_id":"14684328"}}

Значение error_code, равное 0, указывает на успешное принятие команды Talk.

Follow TCP Stream в Wireshark с командой Talk в полудуплексном режиме для канала 1 и успешным ответом 200 OK.

Шаг 5. Подготовка, инкапсуляция и передача аудиоданных Talk.

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

Рекомендуемые настройки аудио:

Кодек: G.711 μ-law
Частота дискретизации: 16 кГц
Аудиоканал: Моно
Размер пакета: 1056 байт
Интервал передачи: 66 мс на пакет

Альтернативный профиль передачи:

Размер пакета: 640 байт
Интервал передачи: 40 мс на пакет

Если микрофон использует другой собственный аудиоформат, например 48 кГц PCM, клиентское приложение должно передискретизировать аудио до 16 кГц, преобразовать в моно и закодировать как G.711 μ-law перед передачей.

Каждый закодированный аудиоблок инкапсулируется в чередующийся двоичный кадр RTSP и передается по выделенному TCP-соединению Talk.

В следующем примере используется рекомендуемый профиль передачи с размером пакета 1056 байт.

$(1B)	Chn ID (1B)	Длина (2B)	Необработанные аудиоданные
0x24	0x00	0x04 0x20	Пример: полезная нагрузка G.711 μ-law размером 1056 байт

Значения, показанные выше, взяты из тестовой реализации:

0x24 — это идентификатор чередующегося кадра RTSP.
0x00 — это идентификатор чередующегося канала, настроенный клиентским приложением для аудиоданных Talk.
0x04 0x20 указывает, что следующие необработанные аудиоданные имеют длину 1056 байт.
Данные после заголовка чередования представляют собой необработанное аудио G.711 μ-law и не содержат заголовка RTP.

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

Подробнее о структуре аудиопакетов Talk см. в разделе 5.4 Talk документа VIGI NVR OpenAPI.

Шестнадцатеричный дамп Wireshark с 24 00 04 20 и полезной нагрузкой G.711 μ-law Talk размером 1056 байт.

Примечание: Выделенные байты в следующем шестнадцатеричном дампе Wireshark соответствуют примеру кадра, показанному выше.

Заключение

Интерфейс потоков VIGI NVR позволяет сторонним клиентам получать доступ к потокам Live View и Playback через стандартные процессы RTSP и RTP. В описанном в этой статье процессе передача аудио Talk использует отдельный сеанс Talk, специфичный для VIGI, для передачи звука с микрофона на выбранный канал камеры.

Вопросы и ответы

В1: Где найти документ OpenAPI VIGI NVR?
О1: Перейдите в Центр загрузок, найдите модель NVR и откройте страницу загрузки продукта. В разделе Руководства загрузите соответствующий документ OpenAPI VIGI NVR.

Показан путь к документу OpenAPI VIGI NVR.

В2: Каковы форматы URL RTSP для Live View и Playback?

О2: Форматы URL RTSP следующие.

Live View:

rtsp://<IP>/live/<канал>/<поток>/avm

Playback:

rtsp://<IP>/replay/<канал>/<поток>/avm?starttime=<время_начала>&endtime=<время_окончания>

канал: Номер канала NVR.
поток: 1 для основного потока и 2 для дополнительного.
время_начала и время_окончания: задают время начала и окончания воспроизведения в формате YYYYMMDDtHHMMSSz для UTC+0. В поддерживаемых прошивках замените z на l и укажите время воспроизведения в локальном часовом поясе NVR; преобразование UTC не требуется.

Примеры:

Пример URL Live View:

rtsp://192.168.0.240/live/1/1/avm

Пример URL Playback с использованием UTC+0:

rtsp://192.168.0.240/replay/1/1/avm?starttime=20260720t154500z&endtime=20260720t161000z

Пример URL Playback с использованием локального времени NVR:

rtsp://192.168.0.240/replay/1/1/avm?starttime=20260720t084500l&endtime=20260720t091000l
Примечание: Суффикс l требует поддержки прошивкой.

В3: Почему в потоке RTSP есть видео, но нет аудио?

О3: Если SDP включает аудиопоток, клиент должен отправить отдельный запрос SETUP для этого потока. Если настроен только видеопоток, клиент получает видео без аудио.

В4: Какой аудиоформат должно использовать клиентское приложение для передачи аудио Talk?
О4: Клиентское приложение должно кодировать звук с микрофона, используя следующие настройки:

Кодек: G.711 μ-law
Частота дискретизации: 16 кГц
Аудиоканалы: Моно
Рекомендуемый размер пакета: 1056 байт
Рекомендуемый интервал передачи: 66 мс

В качестве альтернативы клиентское приложение может передавать аудиоблок размером 640 байт каждые 40 мс.

Если микрофон использует другой собственный аудиоформат, клиентское приложение должно преобразовать аудио в 16 кГц моно перед кодированием в G.711 μ-law.

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