要約

  • P-Refused-URI-List は、特定の参加 PoC サーバーが受信要求内の URI リストを扱えなかったことを示す。そこに並ぶ人が通信を拒否したという記録ではない。
  • members が参照する本文は、ポリシーで許された部分集合にすぎない。開示権限、保護経路、その後の直接 INVITE、端末応答をそれぞれ検証しなければ結果は語れない。

名簿を持つ者と、招待を送る者

この仕組みを理解するには、最初に役割を固定する必要がある。Open Mobile Alliance の Push-to-talk over Cellular では、一つの制御 PoC サーバーが URI リストを解決し、メンバーへ要求を送る。各メンバーのホームドメインには参加 PoC サーバーがあるが、参加側は制御側と同じ権限を持つわけではない。

参加サーバーが、さらに別の URI リストを含む INVITE を受け取ることがある。リストを展開できない、またはその役割を担わない場合、403 と P-Refused-URI-List を返せる。ここで拒否されたのは入力表現の処理である。人や端末が招待を見て拒否したのではない。

障害画面が「グループ拒否」と要約すると、機械の能力不足が人間の意思に化ける。責任主体も変わってしまう。本来は参加サーバーの機能、設定、役割を調べる場面で、利用者の行動を疑うことになる。RFC 5318 の狭い語彙を守ることは、正確な障害対応そのものだ。

開示された人数を母数にしてはいけない

ヘッダーには一つ以上の uri-list-entry を置ける。それぞれは受信要求にあった、処理できなかった URI を示す。members パラメーターが付く場合、その値は MIME 本文の一部を指す Content-ID URL であり、拒否されたリストのメンバー情報がそこに入る。返されたメンバー自体が別の URI リストである場合もある。

ただし、サーバーは開示する意思があるときだけ情報を返す。プレゼンスやプライバシー方針により、全員ではなく一部だけになる。応答に六人いたからといって、元のグループが六人とは限らない。いなかった人について、所属していない、オフラインだった、拒否した、という結論も出せない。

この部分性は欠陥ではない。別ドメインに名簿を渡す危険を抑えながら、制御サーバーに復旧の材料を与える設計である。分析基盤が部分集合を完全な台帳へ昇格させれば、その安全弁を取り外してしまう。

Content-ID の照合も保存すべき証拠だ。ヘッダーだけでは参照先が欠け、本文だけではどの拒否エントリーに属するか分からない。完全な応答、参照関係、元の INVITE を一体で保持する必要がある。パーサーが結び付けたという事実も、バージョンと結果を残すべきである。

403 以外では同じ意味を持たない

仕様は、このヘッダーを 403 以外の応答で使ってはならないとする。柔軟な実装を名乗って他のコードでも取り込むと、診断を定義された失敗経路から切り離してしまう。一方、この拡張は任意なので、ヘッダーがないことも成功の証明にはならない。

IANA はヘッダー名と members パラメーターを登録している。登録は名前の衝突を避け、実装が同じ構文を参照できるようにする。しかし登録証明書は、どの SIP ピアにも通用する信頼契約ではない。RFC 5318 が想定するのは PoC サーバー間であり、単一の制御リゾルバーと特別な信頼関係がある環境だ。公衆インターネット一般には当てはまらない。

この文書が Informational であることも、読み方を整える。プロトコルの提案と条件は確認できるが、現在の製品が実装しているか、方針が正しいか、ログが安全かまでは証明しない。現場の主張には設定、パケット、アクセス制御、製品試験が要る。

暗号化は名簿を渡す権利ではない

セキュリティ節は、通信事業者コア内の信頼されたネットワーク要素と、IPsec や物理的保護を想定する。それでもグループ構成の漏えいを警告し、TLS や S/MIME を推奨する。想定された閉域にいるだけで、名簿が無害になるわけではない。

ここでは二つの問いを混ぜてはいけない。第一に、相手はメンバー情報を受け取る権限があるか。第二に、その相手までの実際の経路は盗聴や改変から守られたか。TLS が正常でも、権限のないサーバーへ安全に漏らすことはできる。正当な相手でも、誤設定された経路なら保護を失う。

さらに、各メンバーを開示してよいかという判断がある。応答単位の許可だけでなく、情報単位の方針が必要だ。証跡には送受信者の同一性と役割、ポリシー判定、チャネル、MIME 完全性、保存先を分けて残す。一つの「secure」フラグでは足りない。

運用ログへの複製も新しい開示である。SIP 交換では許された本文が、長期保存のデータレイクや広い権限のサポート画面に移れば、元の信頼境界は消える。保持期間と二次利用を設計しなければ、復旧機能が恒久的な人物関係データベースになる。

再試行は未来の事実である

制御サーバーは返されたメンバーを使い、直接要求を送ることができる。しかし「できる」は「送った」ではない。RFC 5318 の例からは、通常手順の下で、拒否を返した参加サーバーが対象メンバーへの外向き要求を送らなかったという限定的な負の推論が得られる。それ以上の結果は別途観測する。

直接 INVITE ごとに、対象、時刻、経路、認証、送信、端末応答を記録する。タイムアウト、リダイレクト、端末拒否、成功などは後続イベントだ。信令が成功しても、音声や実際の会話が成立したとは限らない。

初期の 403 レコードを後から「成功」に書き換える設計は因果を消す。失敗は失敗として残し、補救要求を関連付ける。すると、どこでリスト展開が止まり、誰が何を開示し、制御側が何を選び、端末がどう応答したかを独立して説明できる。

実装監査で確かめる項目

元の INVITE、入れ子リスト、両サーバーの役割、403、全ヘッダー値、MIME 部分、Content-ID 対応、開示方針、認可主体、伝送保護、パーサーバージョン、保持区分を保存する。補救を行った場合は、直接要求と応答を新しい記録にする。

403 以外のヘッダー、欠けた MIME、未承認ドメイン、急増する開示人数、新しいログ転送先、パケットのない再試行主張、端末証拠のない成功主張を検知する。任意ヘッダーがないときは「不明」と扱う。空白を都合のよい結果で埋めない。

RFC 5318 は小さな拡張だが、権限設計の要点をよく示す。あるサーバーは、自分が処理できなかった表現についてだけ語れる。必要なら、許された範囲の名簿を渡せる。そこから先の行為と結果は、次の主体の責任であり、新しい証拠が必要である。

参照資料