要約

  • RFC8599は、通知先の情報が変わらなくてもPURRを定期的に更新するよう求める。同時に、関連する対話が続いている間は古い値を保持しなければならない。
  • PURRはプロキシの内部で一意な参照であり、端末の世界共通の識別子ではない。対話ごとの選択、経路、登録の有効性、通知サービスの権限は別々の条件となる。
  • 外部に見せる情報を新しくすることを、内部で負っている責任の終了と取り違えてはならない。小さな共通仕様と、依存関係を持つ当事者の判断を両立させることが重要だ。

最新の登録だけでは答えられない

保守後の確認では、新規の接続を試すことが多い。最新の登録が受理され、新しい参照が返り、次の対話が始まれば、機能は回復したように見える。しかし、その確認では、保守前から続いていた対話が何に依存しているか分からない。新しい値を発行できることは、古い値を解決できることの証明ではない。

説明のため、以前の参照をP1、その後に発行された参照をP2と呼ぼう。これは架空の記号であり、実際の通信記録でも、そのまま送信できる例でもない。P1で始まった対話に、途中の要求が届く。その間に別の登録が行われ、以後の対話ではP2を使えるようになっている。問題は、先の対話が今もP1を使う可能性をどう扱うかだ。

プロキシがP1を消していれば、P2の確認に成功しても先の対話を助けられない。消去の根拠が「新しい値を発行したから」だけなら、まだ続いている依存関係を終了したものとみなしてしまったことになる。プライバシーを改善する作業と、その対話を見失うことに必然的な結び付きはない。

2019年5月に公開されたRFC8599は、この点に二つの義務を置く。第6.2.1節では、プッシュ通知のパラメータが変わらない場合にも、Proxy Unique Registration Reference、略してPURRを定期的に新しく生成することを求める。それと同時に、旧値に関連する対話が継続している間は、その値を保持するよう求めている。

前者は主に、同じ外部参照を手掛かりに長期間の活動を結び付けられることを防ぐ。後者は、既存の対話に必要な関連付けを維持する。対象が違うため、両方を満たせる。更新を理由にすべてを消すことも、継続性を理由に外部参照を永久に固定することも、この区別を捨てた対応になる。

アプリが動いているかは別の条件

モバイル端末では、SIPアプリが常時動作しているとは限らない。登録が有効でも、アプリが休止していれば信号を受け取れないことがある。RFC8599の仕組みは、プロキシがプッシュ通知サービスに通知を求め、ユーザーエージェントが起動して登録を更新できるようにする。

通知は、SIP要求そのものではない。通知サービスが受理したからといって、相手の要求が端末に届いたとはいえない。アプリの起動、登録の更新、その応答、待機していた要求の処理は、それぞれ観察すべき出来事だ。いずれか一つを、残りすべての成功として扱うべきではない。

ユーザーエージェントは、選んだPush Notification Service、PNSからPush Resource ID、PRIDを取得する。その形式はサービスによって異なる。登録時にプロキシへ渡す情報には、サービスの種類、PRID、必要ならサービス固有の追加パラメータが含まれる。

PNSの発見、登録、維持はRFC8599の範囲外であり、すべての事業者に共通のアカウント管理を定めてはいない。この点を忘れると、SIPの登録が続いていることを、通知サービス側の権限が続いていることに読み替えてしまう。

接続、登録の結び付き、通知資源、SIPの対話、個別の要求には別々の期限や終了条件がある。長い対話が続くからといって、削除された登録を使い続けられるわけではない。逆に、新しい登録を受けたからといって、過去に始まったすべての対話が閉じたわけでもない。

登録の処理は個別の結び付きに対して適用される。ユーザーエージェントが複数の結び付きを持つ場合もあり、通知による再登録はそれらを対象にする。説明を簡単にするために、端末一台につき世界共通の登録が一つあると仮定すると、必要な粒度を失ってしまう。

相手に渡すのは通知先の全情報ではない

対話の相手が、その端末の通知サービス上の情報をすべて知る必要はない。RFC8599は、REGISTER以外の要求では、pn-purrを例外として、関連するpn-*パラメータを含めないようユーザーエージェントに求める。pn-provider、pn-prid、pn-paramをそのまま相手に渡さず、限定的な参照を使う。

PURRは、通知を要求するために保存しておいた情報を、プロキシが取り出すための間接参照だ。一意性の範囲はそのプロキシの文脈にある。すべてのネットワークで同じ端末を示すために発行されるわけではなく、世界規模の識別子を割り当てる機関も要らない。

値には、偽造できないこと、匿名であること、プロキシ以外の主体から関連付けられないことが求められる。十分に大きな空間から安全に乱数を選ぶ方式は一つの候補だが、仕様が一つの生成アルゴリズムや保存形式を世界共通で指定しているわけではない。

プロキシ自身が関連付けを知るのは、必要な機能の一部だ。そこまで匿名にしてしまえば、通知先を解決できない。外部で容易に結び付けられないことと、責任を持つ内部の主体が関連付けを維持することは、両立する。

ただし、これはSIP通信全体の匿名性を証明しない。ほかのヘッダー、対話の挙動、運用記録に情報が残る可能性がある。値の性質についての保証を、すべての観察者が何も推測できないという約束へ広げるのは不正確だ。何を隠し、誰が何を知るのかを分けて説明する必要がある。

RFC5627のGRUUとの区別も重要になる。GRUUは特定のユーザーエージェントの実体へ世界的にルーティング可能なURIを提供する。PURRの役目は、このプロキシ内で通知に必要な登録情報を検索することだ。到達可能性に関係するという共通点だけで、識別と検索の範囲を同一視してはならない。

使うかどうかは対話ごとに決める

機能があることは、すべての対話を自動的に参加させる理由にはならない。RFC8599は、途中で届く要求に対してプッシュ通知を使うかどうかを、ユーザーエージェントのローカルな方針に委ねる。対話やメディアの性質によって判断できる。端末全体について一度決めれば、将来のすべての対話が従うという構造ではない。

使うと決めた場合、ユーザーエージェントは、該当する初期Contactにpn-purrを入れる。その値には、直近で受け取ったsip.pnspurrの指示値を使う。指示を受けていないのに、適当な値を作ってpn-purrとして送ってよいわけではない。

Feature-Capsの枠組みを定めたRFC6809は、Contact URIで表されない主体が能力を示す場合を扱う。IANAに登録されたsip.pnspurrは、対話中の要求と登録情報を関連付ける能力を示す。その宣言を、通知サービスに対する包括的な権限や、端末を自由に操作する権利として読むことはできない。

対話の選択、経路、保存された関連付け、登録の有効性、PNSによる受理は、それぞれ違う問いへの答えだ。参照が見つかったことは、登録が削除されていないことの証明ではない。通知サービスが受理したことは、アプリの対話方針が守られたことの証明ではない。

この分担によって、アプリは自分の利用状況に合った方針を持てる。すべての対話に外部の承認を求める必要はない。同時に、運用者は自分の責任をほかの主体の成功で置き換えられない。共通インターフェースは、意思決定を一か所へ集めるためではなく、各判断の接点を明確にするためにある。

保存期間を決めるのは値の古さだけではない

新しい参照が返された時刻は、新しい発行があったことを示す。以前の対話がどの情報を使っているかまでは示さない。後の登録が成功しても、すべての既存対話が最初に覚えた連絡先情報を置き換えたとは限らない。旧値への依存が残るなら、更新と同時に消すことはできない。

RFC8599は、一律の更新間隔や、すべての旧値を削除できる共通の時間数を規定していない。ローカルな清掃予定は便利でも、それだけで関連する対話の終了を証明することはできない。日付を越えたことと、必要な関連付けがなくなったことは別の出来事だ。

その一方、すべての値を無期限に保存するよう求めてもいない。対象は、関連する対話が続いている間の旧値だ。依存が終われば、その継続義務にも終点がある。即時消去か永久保存かという二択ではなく、何がまだ依存し、どう終わるのかを説明することが中心になる。

この点は容量設計にも関係する。現在の登録件数だけでは、まだ必要な関連付けの量を表せない可能性がある。参照を発行する頻度、対話の長さ、依存の終了処理を考慮する必要があるかもしれない。これは運用上の推論であり、ここで測定した規模や、標準が命じるデータ構造ではない。

プロキシの交代を考えると、論点はさらに明確になる。新しいノードが最新の登録を受け継いだとしても、古い対話が使うP1を解決できるとは限らない。保存先を分ける、ノードを交代する、検索の担当範囲を変えるといった作業は、残っている依存に影響し得る。

RFC8599は、共通の複製手順やプロキシ移行手順を用意していない。採用した機能に伴う継続責任は、ローカルな実装で扱わなければならない。作業が難しいことは、すべてのPURRを一つの世界的な台帳に集める必要性の証明にはならない。

経路も継続しなければならない

保存された情報が正しくても、その情報を持つプロキシを後の要求が通らなければ役に立たない。該当する初期対話要求では、プロキシはRecord-Routeに自分を加え、対話の後続要求の経路に残る。RFC3261のルートセットと遠隔ターゲットが、この仕組みの背景にある。

登録に関するPathとは区別が必要だ。RFC3327のPathは、登録済みユーザーエージェントに到達するための中間経路を記録する。Record-Routeは、成立した対話について後の要求がたどる経路を扱う。登録側の経路情報だけで、PURRを持つプロキシへ対話中の要求が届くと証明することはできない。

RFC5626のユーザーエージェントから開始する接続、保活、複数接続も、また別の到達性の条件を扱う。NATやファイアウォールの制約への対処は、休止中のアプリがすぐ信号を受け取れることと同じではない。接続、登録、対話経路、通知を一つの状態としてまとめると、どの境界で失敗したか分からなくなる。

第6.2.3節の対話中要求では、pn-purrがRequest-URIかRouteのURIに現れる。どちらになるかはルートセットの構成による。プロキシが保存情報を取り出せる場合、要求を待機させ、通知を求める。関連するREGISTERトランザクションの2xx応答を受けると、対応する対話中要求を取り出して転送する。

この場面では第5.3節のURI比較を行わない。対話中要求には、非公開にしたpn-prid、pn-provider、pn-paramが含まれないためだ。関連するPURRと登録応答によって待機要求を特定する。間接参照は見た目だけの変更ではなく、関連付けの処理にも違いを生む。

この説明の範囲は対話中要求に限られる。初期要求には別の条件や、トランスポートに応じた順序がある。すべてのSIP要求が、例外なくREGISTERの2xxを待つと一般化してはならない。プライバシーの説明を簡単にするために、周囲のプロトコルを別物にしてしまうべきではない。

残す義務と、使ってよい権限は同じではない

旧参照がまだ対話で使われていても、底にある登録が消去された場合には別の限界が働く。プロキシが登録の結び付きの失効や削除を知らされたら、そのPRIDで追加のプッシュ通知を求めてはならない。旧PURRの保持は、終了した登録を復活させる手段ではない。

通知サービスの資源が無効になった場合も、対話が続いているという理由だけでは解決しない。プロキシが知っている関連付けと、サービスが受け付ける権限は異なる。前者を保持することから、後者が永久に存在すると推測してはならない。

待機中の要求にも期限がある。通知と登録を待つ間に、要求を送った側のトランザクションがタイムアウトする可能性がある。RFC8599はこれを明示し、必要以上に対話全体を傷つけず、当該トランザクションを主に対象とするエラーの選択を勧めている。

通知サービス固有の認証や認可は、それぞれの仕様が定める。RFC8599はSIP信号の適切な保護も求める。さらに、登録イベントの通知などを通じて、通知先の非公開パラメータがほかの利用者や信頼できない主体へ渡らないよう配慮が必要だ。初期Contactだけを確認して終わりにはできない。

RFC8030はHTTP Web Pushの安全性を説明するが、SIPアプリの対話別方針を決めない。通知の受理、参照の解決、対話の成立は別々の事実である。これらを一つの万能な権限と呼ぶと、不必要な起動や電池消耗が起きたとき、誰の判断が原因か見えにくくなる。

したがって、保存と使用を同じスイッチにしてはならない。続いている依存を忘れない一方で、終了した登録や失われたサービス権限に基づく通知は止める。この二つを分けられることが、限定された継続責任を正しく扱う条件だ。

公開文書が示すこと、示さないこと

対象版を固定したOpenSIPS3.6のregistrar文書は、pn_enable_purr、pn_process_purr、設定可能なpn_refresh_timeoutを説明する。能力を有効にすること、参照を検索すること、要求を待機させることが、別々の実装上の要素になると分かる。

2020年の二つのOpenSIPS解説も、登録更新と対話中要求の扱いを説明する資料になる。ただし、過去の実装説明を、現在の特定のクラスタで旧値が正しく保持・複製されている証拠として使うことはできない。本調査では、運用中のSIP設備へ要求を送ったり、その動作を試験したりしていない。

勘違いを避けるには、正誤表の状態も重要だ。8136は検証済みの編集上の訂正で、第4.1.4節のsip.pnsreqをsip.pnsregに直す。7136はREGISTER Request-URIの例に関する報告済みの技術上の指摘であり、受理された規範変更ではない。

機能の存在、仕様上の義務、実際の運用で満たされたことは三つの段階だ。名前の一覧や昔の使用例は最初の段階を説明できても、最後の段階を代行しない。この範囲を正直に示す方が、未実施の試験を想像で補うより、判断に役立つ。

結論は明快である。参照更新は、外部に見せる値の継続性を減らすために行う。しかし、その時点で既存の対話が持つ依存まで消えたと考えてはならない。必要な情報は責任を持つローカルなプロキシに残し、実際の終了条件は別途守る。それ以上の世界的な承認機構は、ここから必然的には導かれない。

出典