Кратко

  • Каждая пара кадров RFC 3557 представляет 20 мс признаков речи. Четыре пары в одном пакете экономят три комплекта заголовков, но потеря этого пакета создаёт один непрерывный 80-миллисекундный пробел.
  • Четырёхбитовый CRC проверяет только полученную пару. Разрыв RTP-последовательности и временной шкалы, карта пропавших пар, приём движком, результат распознавания и действие приложения требуют отдельных свидетельств.

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

RFC 3557 опубликована в июле 2003 года как Proposed Standard. Она задаёт RTP-формат признаков распределённого распознавания речи, полученных фронтендом ETSI ES 201 108. Документ не сообщает о внедрении, аварии или качестве модели. Он даёт точную арифметику, по которой транспортный разрыв можно перевести в отсутствующее время признаков.

Двадцать миллисекунд — базовая шкала доказательства

Фронтенд формирует 44-битный квантованный вектор признаков каждые 10 мс. Два последовательных вектора образуют Frame Pair, или FP, представляющую 20 мс исходной речи. К ним добавляются четыре бита CRC и четыре нулевых бита заполнения, так что FP занимает 96 бит, или 12 октетов.

RTP-полезная нагрузка содержит одну или несколько FP подряд. Временная метка относится к моменту первой выборки, представленной первой парой. Для каждой следующей пары она увеличивается на 160, 220 или 320 отсчётов при частоте 8, 11 или 16 кГц.

Такая регулярность позволяет вычислить ожидаемую последовательность. Если номер RTP-пакета перескочил, а временная метка следующего пакета ушла вперёд на четыре пары, наблюдатель может зафиксировать 80 мс отсутствующих признаков. Это вычисление не говорит, почему пакет исчез и как на пробел отреагировал движок, но точно ограничивает недостающее.

CRC у следующей пары остаётся полезным, но узким доказательством. Он не аутентифицирует источник, не исправляет потерю, не проверяет пропавшие FP и не подтверждает приём движком. Валидность после пробела не распространяется назад.

Считайте пропавшее время, а не только пакеты

При одной FP на пакет единичная потеря убирает 20 мс признаков. При четырёх FP она может убрать 80 мс подряд. Сетевой счётчик в обоих случаях увеличится на единицу, но семантический масштаб события различается вчетверо.

Меньшая агрегация сокращает задержку ожидания и ограничивает непрерывный пробел, однако увеличивает накладные расходы RTP, UDP и IP. Большая агрегация экономит заголовки, но требует дольше ждать отправки и объединяет судьбу большего временного участка. RFC 3557 отмечает трудности большинства распознавателей при потере большого числа последовательных FP.

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

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

maxptime переводит пакетную политику во время

Параметр maxptime задаёт максимальную медиадлительность пакета и должен быть кратен 20 мс. Если он отсутствует, RFC 3557 предполагает 80 мс. При ожидаемой высокой доле потерь участник может выбрать меньшую величину.

Значение 80 мс допускает четыре FP. Это может удалить три дополнительных комплекта заголовков по сравнению с одной FP на пакет. Оно же определяет возможную длину одного последовательного провала. Поэтому maxptime — не декоративное поле SDP, а ограничитель экспозиции.

Объявленное значение само по себе не доказывает фактическую упаковку. Отправитель мог вести себя иначе; сеть могла переупорядочить или потерять пакет; движок мог отвергнуть часть потока. Сопоставляйте декларацию с наблюдаемым числом FP, RTP-последовательностью, временной меткой и временем отправки.

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

Временная метка ограничивает пробел, но не объясняет его последствия

RTP-время помогает определить, сколько медиавремени должно было пройти между полученными пакетами. Номер последовательности помогает отличить отсутствие пакета от обычного продолжения. Структура FP позволяет перевести разрыв в число пар.

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

Сжатие заголовков по RFC 2508 или RFC 3095 может позволить сократить пакетный интервал без прежней цены заголовков. Но его контекст тоже должен быть наблюдаемым: теоретическая поддержка не равна рабочему состоянию. RFC 2198 даёт соседний контекст избыточности, однако агрегация RFC 3557 сама по себе резервной копии не создаёт.

Null FP завершает сегмент отправителя, а не расследование

RFC 3557 поддерживает прерывистую передачу. Фронтенд посылает FP, пока обнаруживает речь. Непрерывный интервал, направляемый движку, называется сегментом передачи и может включать речевые и неречевые кадры.

После того как число последовательных неречевых кадров превысит настроенный hangover-порог, отправитель завершает сегмент. Документ приводит 1,5 секунды как типичную величину, а не обязательный оптимум. Затем фронтенд должен отправить одну или несколько Null FP.

В Null FP поля признаков заполнены нулями, а CRC и заполнение рассчитаны обычным образом. Это внутрипоточный маркер границы по мнению отправителя. Он не доказывает доставку предыдущего пакета и не сообщает, что движок закрыл тот же сегмент.

Null FP может прийти после разрыва и иметь корректный CRC. Тогда журнал должен одновременно сохранить два факта: маркер конца получен; перед ним отсутствуют такие-то FP и столько-то миллисекунд. Первый факт не отменяет второй.

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

После транспорта меняется субъект утверждения

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

Приложение отдельно решает, достаточно ли результата для действия. RTP-журнал не подтверждает ingest. Ingest не подтверждает правильность распознавания. Результат модели не авторизует финансовое, доступное или критичное действие без политики приложения и, где нужно, человека.

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

Граница доказательств

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

RFC 3550 и RFC 3551 ограничивают контекст RTP. RFC 2327 показывает SDP-контекст времени публикации, RFC 8866 — более поздний статус. RFC 2508 и RFC 3095 описывают альтернативы сжатия; RFC 2198 — соседний контекст избыточности, а не свидетельство её использования здесь.

Эссе Heng Lu Running-Code Primacy и Minimum Initial Specification используются как явно раскрытые редакционные линзы. Они помогают не путать опубликованный формат с работающим поведением и отделять минимальное общее основание от локальных решений. Они не доказывают намерения авторов RFC или событие сети.

Ограниченный вывод точен: агрегация может уменьшить число заголовков и увеличить длительность признаков под одним риском потери. Временная шкала и структура FP помогают измерить пробел. Только последующие квитанции показывают, что принял движок, что распознала модель и что сделало приложение.

Источники