200 OK は Auto と答えた。それでも人が不在だったとは証明していない。

要約

UAS は INVITE への 200 に Answer-Mode または Priv-Answer-Mode を入れ、手動か自動かを通知できる。プッシュ・ツー・トークの話者は、その違いを知れば話し方を変えられる。しかし Manual は、現実の人が端末を操作した可能性を外部へ知らせる。

そのため RFC は、応答への掲載を方針で制御し、既定では省略することを推奨する。省略は Auto の略記ではない。Manual の否定でも、非対応の証明でもない。「この応答面では開示しなかった」という未知値である。

掲載された値にも限界がある。Manual は操作した人物の身元を証明しない。Auto は周囲に人がいなかったことを証明しない。SIP の受理は、人が音を聞いたか、理解したか、業務判断をしたかを観測しない。

Answer-Mode: Auto は、利用者入力を待たない受理を求める。認証・認可された呼出元でも、UAS は利用者設定や媒体リスクに従い、手動扱いまたは拒否を選べる。

;require が付くと、方針が別のモードを選んだ場合に手動へ落とさず拒否する。これは「自動にせよ」という権限ではなく、「自動でなければ成立させない」という呼出元側の許容条件である。

一方の Require: answermode は拡張理解の必須条件にすぎない。理解した UAS に自動動作を強制できない。REGISTER の機能タグや Accept-Contact も、対応候補の探索資料であって、その通話への認可ではない。

RFC は Priv-Answer-Mode を sudo にたとえる。接頭辞は特権処理を依頼するが、特権そのものを運ばない。既定方針は、要求者が認証され、この用途を明示的に許可されていなければ拒否することである。

同じ人物でも、通常は普通の要求を送り、緊急時だけ特権方針を求められる。身元だけで全通話を昇格させれば、この意図差が消える。両ヘッダーが届いた場合、UAS は特権認可を先に調べ、失敗すれば通常要求を処理する。

監査には、提示身元、認証方式、選ばれた方針表、規則版、通常へのフォールバックを残す必要がある。2008年に参照された RFC 4474 は RFC 8224 に置き換えられたため、歴史的参照を現代の実装証明にしてはならない。

スピーカーへの受信媒体は迷惑音、費用、電池消費を生み得る。端末からの送信媒体は、マイクやカメラを通じて私的空間を露出し得る。RFC は後者により強い境界を置く。

利用者の明示承認なしに、UAS は自らを送信源とする送信専用または双方向媒体を確立してはならない。診断ループバックは、試験信号を返すのであって室内を取得しないため例外になる。

対話が受信専用で自動開始しても、後の re-INVITE や UPDATE で方向が変わることがある。Answer-Mode 自体は中間要求に定義されないが、媒体保護は対話状態を追跡し続ける。新しい送信には新しい人の承認が要る。

一つの INVITE が複数 contact に並列 fork されると、複数端末が自動で 200 を返せる。通常は最初の対話を残し、他へ BYE を送る。しかし敗者側のスピーカーが BYE 前に媒体を再生した可能性は残る。

最終対話だけを保存すると、その作用が消える。RFC が並列 fork 環境で auto-answer を推奨しないのは、複数受理が単なる重複ログではないからだ。contact、各枝の200、媒体開始、BYEまでの時間を記録する必要がある。

通常の中間 proxy はヘッダーを無視する。サービス proxy が挿入・削除・変更できるのは、利用者との明示的な外部合意がある場合だけである。そうでなければ、診断呼を人に取らせたり、意図しないスピーカー動作へ変えたりする。

受信した値は、常に発呼者の原文とは限らない。原要求、許可された変換、proxy 身元、合意版、UAS が評価した最終バイトを結び付けるべきである。

保存対象は、初期 INVITE、身元と認証、通常/特権の選択、二つの require、contact と全 fork、proxy 変換、UAS 方針、応答と開示有無、対話版ごとの SDP 方向、明示承認、実際の媒体パケットである。人の存在、注意、理解、結果は別の観測とする。

これにより「ある UAS が、ある方針で要求を処理した」と言える。Auto の一語を、人間についての物語に拡張する必要はない。