要約

  • 旧EVRC-B実装はRFC 5188の新しいmode属性を送信せず、受信しても無視できる。欠落だけからmode、拒否、非準拠を決めてはならない。
  • mode-set-recvとrecvmodeは受信側の希望であり、送信側は無視できる。sendmodeも実行そのものではなく、RTPより遅れて届き得る状態宣言である。

Answerからsendmodeが消えた。監視は「mode交渉失敗」と記録したが、音声は続いていた。相手は新属性を理解しない旧EVRC-B実装で、仕様どおり未知の情報を無視していた。

見えないものをゼロや拒否に変換すると、互換性が障害に見える。逆に、欠落を常にlegacyと決めれば、本当に失われたSDP更新を見逃す。必要なのは推測ではなくversionと観測の分離である。

不在には複数の原因がある

RFC 5188はRFC 4788のaudio/EVRCBとaudio/EVRCB0へrecvmodeとsendmodeを追加した。旧実装は新属性を送らず、受け取っても無視することで相互運用を維持する。

したがって属性不在は、旧peer、新実装による任意属性の省略、middleboxの正規化、capture欠落、古いSDP versionのどれでもあり得る。追加証拠なしにmode 0を補うことは、unknownを実行状態へ書き換える行為だ。

未知のoffer parameterは無視し、answerへ含めてはならない。理解しない値をechoすると、共有していない意味について合意したように見える。省略は機能不足ではなく、偽の合意を防ぐ境界になり得る。

希望と決定は別の主体が持つ

EVRC-WBのmode-set-recvは受信側が望むremote encoder modeの集合を示す。EVRC-Bのrecvmodeは一つの希望modeを示す。いずれもreceive-onlyである。

remote senderはこの希望を無視できる。受信側は希望外のmodeでもdecodeを続けられる。RFC 5188の例では、offererがmode 0を受信可能としていてもanswererはmode 4で送信する。

よって記録すべき状態は、希望を受領したか、送信policyが尊重したか、何をsendmodeで宣言したか、encoderがいつ何を実行したかである。希望欄の存在を「適用済み」に変えると、remote encoderの権限をSDP parserが奪ってしまう。

方向を失った属性は証拠にならない

mode-set-recvとrecvmodeは受信方向、sendmodeは送信方向にだけ意味を持つ。sendonly streamで受信希望を掲げても対象mediaがない。recvonly streamのsendmodeも同様である。

証拠には値だけでなく、宣言者、方向、payload binding、offer/answer versionが必要だ。自動変換が両方向へ同じfmtpを複製すると、文字列は整うがauthorityが消える。

Controlの宣言はmediaより遅れ得る

sendmodeはsenderのcurrent modeを知らせる。しかしRTP mediaは初回または更新sendmodeを含むSDPよりかなり先に到着し得る。

encoderがT1でmodeを変更し、packetがT2、SDP更新がT3に届くなら、T1からT3のlast-known SDPは古い。T3の文書も過去packetへ自動的な時刻を与えない。

offer/answer version、encoder transition、RTP sequenceとtimestamp、到着、decoder ingestionを同じtimelineで照合する必要がある。遅い宣言は直ちに違反ではなく、長い不一致も「最終的に更新された」で消してはならない。

Codec名とclockは実行結果ではない

audio/EVRCWB、EVRCWB0、EVRCWB1はそれぞれpacket formatを選ぶ。payload selectionはbytesの解釈規則を確立するが、各区間のmodeを確定しない。

EVRC-WB mode 4と7はEVRC-Bと相互運用する。offererはEVRC-Bも提示し、旧answererがfallbackできるようにする。選択されたcodec family、receiver preference、sender modeは別々の事実である。

EVRC-WBのRTP clockは常に16 kHzだが、encoder inputやdecoder outputは8 kHzでもよい。/16000はtimestamp尺度であり、microphoneやspeakerのbandwidth receiptではない。

EVRCWB1ではsession identityが決定的になる

EVRCWB1はsession全体で同じfixed rateとmodeを使わなければならない。同一sessionの途中でmodeが変われば、通常形式の許容transitionとは異なる問題になる。

ただし後から届いたSDPだけで違反も正当化もできない。旧bindingが終了した時点、新sessionまたは新payloadが始まった事実、各packetの所属を示す必要がある。固定条件は時間とidentityの証明を強くするが、receive preferenceをexecution receiptには変えない。

保存すべきreceipt

immutable session/change ID、endpoint role、direction、offer/answer version、payload、subtype、clock、raw rtpmap、fmtp、ptime、maxptimeから始める。

次にreceiver preference、そのowner、sender policyの判断、sendmode値と到着時刻、encoder transition、関連frameのsequence・timestamp・到着・modeを保存する。legacy capability、unknown parameter処理、EVRCWB1 invariantも明示する。

最後にdecoder acceptance、output、application outcomeを置く。decode成功は希望充足ではなく、希望充足は音質証明でもない。各layerは自分の事実だけを語る。

Leadership判断

欠落を埋めるのではなく、欠落の理由を分ける。希望を命令にせず、宣言を実行にせず、最終SDPを過去全体に広げない。

この分離が、legacy interoperabilityと説明責任を同時に守る。最後の文書だけを残した組織は契約を読めても、実際のmedia historyを証明できない。

情報源

  1. RFC 5188 HTML
  2. RFC 5188 text
  3. RFC 5188 info
  4. Datatracker RFC 5188
  5. RFC 5188 history
  6. RFC 5188 references
  7. RFC 5188 errata
  8. RFC 4788
  9. RFC 4788 info
  10. RFC 3558
  11. RFC 3558 info
  12. RFC 3264 Offer/Answer
  13. RFC 3264 info
  14. RFC 4566 SDP
  15. RFC 3550 RTP
  16. IANA audio/EVRCWB
  17. IANA RTP parameters
  18. Heng Lu—reality layers
  19. Heng Lu—minimum initial specification
  20. Heng Lu—running code primary