要約

  • RFC 3557 は 10 ms の特徴フレーム二つを 20 ms の Frame Pair にし、4 bit CRC とパディングを加え、複数を RTP に連結する。
  • 集約はヘッダを節約する一方、待ち時間と一回の損失範囲を増やす。Null FP、CRC、timestamp は限定された事実しか語らず、認識成功の受領証ではない。

2003 年 7 月に Proposed Standard として公開された RFC 3557 は、端末の DSR フロントエンドから音声エンジンへ特徴表現を送る形式を定めた。実運用の精度報告ではない。

受信単位の CRC と列の完全性を分ける

44 bit の特徴が 10 ms ごとに生成され、二つで FP となる。4 bit CRC と 4 bit のゼロを加え、96 bit、12 octet にそろえる。

受信側は届いた FP の CRC を確認できる。失われたパケット内の FP には検査を実行できない。残存単位がすべて正常でも、列が完全とは限らない。

RTP sequence、timestamp、含まれる FP の対応を保存し、欠損を個数と時間へ変換する。packet loss 一件という記録では、20 ms と 80 ms を区別できない。

集約は故障範囲を時間方向に広げる

FP を少なくすれば送出は早く、一つの損失が覆う時間も短いが、ヘッダは増える。FP を増やせば効率は上がるが、集まるまで待ち、一つの datagram がより長い連続特徴を抱える。

RFC は、多数の連続 FP 欠損が多くの認識器に難しいと述べ、帯域効率を満たす範囲で個数を小さくし、ヘッダ圧縮も検討するよう勧める。

小さいパケットが常に正解という意味ではない。損失分布、遅延、処理、圧縮、エンジン耐性を同じ版の判断として残すことが重要である。

maxptime を実測する

maxptime は一つの packet に含める最大媒体時間で、20 ms の倍数が望ましい。省略時は 80 ms とみなされ、高損失を想定する場合は短くできる。

80 ms は四つの FP である。宣言を見ただけでは送信実装が守ったか分からない。timestamp と構成から実時間を観測し、違反をリスク拡大として扱う。

RFC 2508 と RFC 3095 の圧縮は別の選択肢を示す。機能があるだけで文脈が有効とは限らない。RFC 2198 の冗長化も自動ではない。集約された一次データに複製はない。

Null FP は終端であって完全性ではない

DTX は音声検出時だけ送る。連続無音が hangover を超えると送信側は segment を閉じる。1.5 秒は典型例であり普遍値ではない。その後、一つ以上の Null FP を送ることが推奨される。

Null FP は二つの特徴部をゼロにし、通常の CRC と padding を持つ。送信側の終端判断を運ぶが、直前の packet を再送しない。

したがって、正しい終端が欠けた本文の後に届くことがある。最後の実 FP、Null 試行、sequence gap、受信、engine close を別々に記録する。終端は未知を消去しない。

認識とアプリケーションは後段である

エンジンは並べ替え、FP 検査、gap 処理、concealment、segment close を行い、特定モデルが仮説と confidence を出す。アプリケーションが確認、再質問、拒否、実行を決める。

RTP 到着は ingestion ではない。ingestion は正答ではない。仮説は行為の権限ではない。各主体が自分の受領証を出す必要がある。

圧縮は集約以外の選択肢を作る

RFC 3557 は、RFC 2508 と RFC 3095 による IP/UDP/RTP ヘッダー圧縮を参照している。したがって、効率化は「ヘッダーを繰り返すか、より多くの FP を一つに束ねるか」だけの二者択一ではない。圧縮コンテキストが安定していれば、短い媒体区間を維持しながらヘッダー費用を下げられる可能性がある。

ただし、圧縮機能の存在は稼働状態の証明ではない。コンテキストが未確立、失効、または頻繁に修復されていれば、紙上の代替案と運用上の代替案は異なる。方式、実効ヘッダー長、コンテキスト状態、修復履歴、適用経路を記録して初めて、集約との比較が成立する。

RFC 2198 は冗長音声の近接する文脈を与えるが、RFC 3557 の集約だけで予備コピーが生まれるわけではない。四つの一次 FP を同じパケットに入れれば、四つは一つの配送運命を共有する。

gap を独立した監査対象にする

監査可能な時系列は、取得区間、特徴ベクトル、FP の組、CRC、パケット内一覧、RTP シーケンスとタイムスタンプ、到着、欠落・並べ替え判定、engine ingestion、欠落処理、モデル出力、アプリケーション処置を分けて保持する。後段の成功で前段の空白を埋めてはならない。

この分離は設定変更の比較にも必要である。集約を増やす前に、損失分布、圧縮状態、遅延、エンジンの許容範囲、再試行率を基準化する。変更後は同じ指標を、識別可能なポリシーバージョンとともに比較する。バージョンがなければ、認識結果の変化とパケット化を結び付けられない。

ダッシュボードには少なくとも二軸が要る。削減したヘッダーバイトと、一回の損失にさらした連続ミリ秒である。パケット数だけなら 20 ms と 80 ms の欠落が同じ一件に見える。認識エラーだけなら、不完全な入力と完全な入力に対するモデル判断を区別できない。

証拠の限界

利用者、声、言語、端末、エンジン、モデル、事業者、サービス、事故を特定せず、損失率、精度、採用率、最適値を主張しない。80 ms は仕様上の既定値である。

RTP、SDP、圧縮、冗長化 RFC は隣接境界であり導入証拠ではない。Heng Lu の二つの論考は、仕様と実行結果を分ける明示した編集視点で、著者意図を証明しない。

結論は限定的である。Null FP は送信側の区間を閉じる。前の特徴列、認識、行為は、それぞれ別の証拠で閉じなければならない。

Sources