要約

  • RFC 5347のSDP能力宣言は、現在または潜在的にT.38を扱えることを示せるが、Call Agentが現在の命令で切替を許可した証明にはならない。能力と権限は別の証拠である。
  • Strictは能力証拠がない相手への危険な試行を避ける代わりに、実際には対応可能な相手を拒むことがある。Looseはその偽陰性を減らす一方、非対応相手へ切り替える偽陽性を増やし得る。普遍的な正解はない。
  • t38(stop)はゲートウェイが検出したエラーなしに手続が終わったことだけを示す。ページ送信、完全性、遠隔受理、人による受領は別の確認を必要とする。

能力は未来形、許可は現在形である

能力宣言は、装置が現在使っている形式だけでなく、条件が整えば使える形式も伝えられる。相互運用の候補を見つけるには有用だが、どの候補をこの接続で実行してよいかまでは決めない。

Call Agent制御モードでは、明示されたfax LocalConnectionOptionがその決定を担う。t38が現在の命令に含まれ、必要な遠隔証拠も同じ命令に伴って初めて、Strict選択を受け入れる根拠が成立する。

能力広告だけを見て自動切替する実装は、発見情報に命令権を与えてしまう。逆に、明示許可だけを保存し、当時の能力証拠を捨てると、なぜ命令が受理または拒否されたか説明できない。

監査では、能力の値、由来、時刻、対象、現在命令、明示オプションを別々に保持すべきだ。「T.38対応」という一つのフラグでは、技術可能性と運用許可のどちらを指したのか判別できない。

広告がないことも非対応の証明ではない

相手がT.38を実装していても、RFC 3407の想定する方法で能力を表現できない場合がある。Strictは利用可能な宣言を要求するため、その相手との成立可能なfaxを拒否し得る。これは証拠不足から生じる偽陰性だ。

Looseは能力宣言が欠けてもT.38を試せる。そのため偽陰性を救える一方、実際に非対応の相手にも切替を試み、fax全体を失敗させる可能性がある。これは偽陽性の危険である。

RFC 5347はどちらかを万能な答えとして扱わない。端点の性質、能力広告の信頼性、失敗コストによって選択は変わる。

したがって設定レビューで問うべきなのは「StrictとLooseのどちらが正しいか」ではない。どの相手群で、どの証拠欠落を、どの失敗と引き換えに許容するのかを明文化できているかである。

省略された方針は同じ効力を持たない

RFCの決定的な例では、接続はまずT.38 Strictで正常に確立される。後のModifyConnectionには、T.38を支えないRemoteConnectionDescriptorが含まれる。

faxオプションを省略すると、命令は成功する。現在値は保持されるが、今回の受理条件としてT.38が再要求されたわけではない。その後faxを検出してもT.38は呼び出されず、nopfax(start)が発生する。

同じ変更で t38を明示的に繰り返せば、命令は失敗しなければならない。要求された手続を満たせない場合はエラー532が推奨される。拒否は、保証を失ったまま接続だけを緑にすることを防ぐ。

設定データの最終値だけでは両者を区別できない。値に加えて、その値が現在のトランザクションに存在したか、省略で継承されたかを証拠として残す必要がある。

選択と送信は別の時刻を参照する

現在の命令で手続を選ぶ際、以前に受信したRemoteConnectionDescriptorは根拠にならない。選択へ影響できるのは現在の命令に含まれる記述だけである。

媒体送信では規則が異なる。実際にT.38を送る前に、最後に受信した遠隔記述に対応するimage/t38行と利用可能なトランスポートが存在しなければならない。手続を先に開始することはできるが、パケットはその許可を待つ。待機が期限切れになれば停止または失敗となる。

前者は「この命令が何を成立させられるか」、後者は「今この瞬間に何を送れるか」を答える。時間軸を一つに畳むと、選択時には正しかった判断と、送信時には失われた許可を区別できない。

ログには各命令へ結びつく記述と、各送信時点で最新だった記述の両方が必要だ。さらに待機開始、許可更新、最初の送信、タイムアウトをつなげなければならない。

優先リストには到達不能な枝がある

t38はCall Agent管理のStrict、t38-looseはLoose、gwは方法と詳細をゲートウェイへ委任し、offは局所調整を除いて特別なfax手続を求めない。

セミコロン区切りは優先順位に見えるが、すべてが失敗可能な候補ではない。t38-looseとoffは常に支持可能なので、それ以後の選択肢は到達不能になる。

gwには別の例外がある。委任した結果が特別処理なしになる場合、後ろにあるoff以外の手続へ進める。文字列の並びだけを検査する汎用バリデータでは、この制御フローを見落とす。

運用画面は各項目の正当性だけでなく、順序による死んだ枝、gwからの特別な継続、最終選択理由を示すべきである。長いリストは冗長性の証明にならない。

委任の不足はfax開始まで見えない

ゲートウェイ制御モードで特別処理が成立するには、両側が同じ方式を支持し、それが交換されたSDPで示される必要がある。方式の詳細はベンダーが決める。共通方式がなければ特別処理はない。

Call Agentは命令応答の時点でその不足を知れない場合がある。faxが始まり、nopfax(start)が届いて初めて、委任先に実行可能な特別方式がなかったと分かる。

実際に委任方式が開始すればgwfax(start)が通知される。以後Call Agentは終了まで競合する命令を避けるべきだ。委任には開始確認と非干渉期間の尊重という二つの義務がある。

gwが設定されている事実だけでは、共通方式、開始、継続、成功のどれも証明しない。それぞれを独立した状態として表示しなければならない。

手続の緑と文書の緑を分ける

t38(start)はfax検出とCall Agent管理手続の開始を示す。t38(stop)はゲートウェイがエラーを検出せずにT.38手続が終わったことを示す。しかしRFC自身が、fax送信成功を必ずしも意味しないと明記する。

ページ数、文書完全性、遠隔アプリケーションの受理、正しい宛先、人の受領は範囲外だ。t38(failure)は異常終了を示すが、stopがfailureでないだけでは業務成功に届かない。

gwfaxイベントも委任手続のライフサイクルを表すだけである。nopfax(start)にはstopやfailureがない。特別処理をしないモードでは、媒体からfax終了を推測することが期待されていないためだ。

手続結果と文書結果には別の所有者、別の確認時刻、別の信頼水準を割り当てる必要がある。ネットワークイベントから業務結果を自動補完してはいけない。

検出信号も完全ではない

実装は少なくともV.21プリアンブルからfaxを検出する。T.30のCNG呼出音は任意である。RFCは、非fax呼でもモデムがCNGを出し、誤ってfax切替を起こした事例を記し、CNG検出を無効化できる設定を推奨する。

正しい権限、正しい方法、正常なstopがそろっても、開始信号自体が誤りならfax文書は存在しない。各段階の内部整合性から入口の事実を逆算できない。

発信側、着信側、または両方が同時にT.38切替を開始できる。同時開始を処理できなければならない。検出器、信号、開始端点、時刻、競合解消を証拠へ含めるべきだ。

同じポートでも期待媒体は変わる

RTP音声とT.38の切替で同じIPアドレスとポートを使うことは、QoS、NAT、ファイアウォールへの影響を抑える。しかし五つ組から媒体種別を判断できなくなる。

どの種別を期待するかは明示信令が決める。受信側は期待形式に照らして検証し、パケット内容を見て都合よく多重分離するべきではない。

UDPTLやT.38属性の大文字小文字、過去の誤った真偽値表現への寛容も、相互運用上の救済にすぎない。合意された方針や到達結果の証明ではない。

faxパケットとオクテットは接続カウンタに含める一方、fax中はジッタや平均遅延の計算を停止できる。重要な切替中に監視が空白になる可能性を、正常値として扱わない注意が要る。

文書の地位が主張の範囲を決める

RFC 5347は2008年10月発行のInformational文書であり、Internet Standardではない。RFC Editorのerrata検索には、文書更新用として保留された六件が示される。運用解釈ではこの状態も提示すべきである。

本文だけから現在の製品挙動、市場採用率、特定網の構成を主張することはできない。T.38があらゆるfax成功の必須条件だとも言えない。

それでも、能力と許可を分け、現在命令と最新状態を分け、手続と成果を分ける設計原則は現在も有効だ。自動化が多くなるほど、発見した能力を無断で実行へ変換しない規律が重要になる。