要約

  • PRACK は特定の信頼できる仮応答を確認する。PRACK に対する 2xx は、元の INVITE を受諾したという最終回答ではない。
  • RSeq と RAck は対話、CSeq、順序を結び付ける。仮応答で offer/answer が進んでも、メディア到達や人が聞いた事実までは証明しない。

100 Trying を対象外にした理由

RFC 3261 では、INVITE の最終回答に先立って複数の 1xx が返り得る。101 から 199 は呼出しの進行を示し、To タグがあれば early dialog を作る。一方、基礎仕様の仮応答は信頼できる配送ではなかった。

RFC 3262 は、この不足をすべての 1xx に一律適用する方法では埋めなかった。100rel をサポートした INVITE に対し、UAS は 100 以外の仮応答を信頼できる形で送れる。INVITE が Require: 100rel を含むなら、UAS はそれに従うか、拡張要求を拒まなければならない。

100 Trying は明示的に除外された。100 はホップごとの応答であり、RFC 3262 の確認はエンドツーエンドだからである。この境界から、PRACK は単なる再送機能ではなく、どの範囲の主体が何を確認するかを定めた仕組みだと分かる。

RSeq は通話番号ではない

信頼できる仮応答は Require: 100rel と RSeq を持つ。最初の RSeq は規定範囲から選ばれ、番号空間は一つのトランザクションに閉じる。別の INVITE で同じ番号が現れても、同じ応答を意味しない。

UAS は T1 から始まる指数バックオフで仮応答を再送する。止めるのは、同じ dialog に属し、RAck が一致する PRACK である。RAck には仮応答の RSeq、元の CSeq 番号、方法名が並ぶ。応答番号だけを照合するより狭く、具体的な中間状態を指せる。

対応する未確認応答があれば PRACK 自体に 2xx が返る。対応がなければ 481 である。ここで 2xx の対象を取り違えてはいけない。成功したのは PRACK という別トランザクションであり、INVITE が受諾されたわけではない。

PRACK は ACK と似た役割を果たすが、ACK の一種ではない。dialog 内の通常の非 INVITE 要求で、自分の CSeq と応答を持ち、状態を持つプロキシを通じてホップごとに信頼性を得る。この独立性が、仮応答の受領と最終判断を切り分ける。

一つずつ確認する設計

確認は累積しない。RFC 3262 は輻輳制御のため、未確認の信頼できる仮応答を一つに抑えるよう推奨し、少なくとも最初の応答が確認されるまで二つ目を送ることを禁じる。後続 RSeq は必ず一つずつ増え、周回しない。

受信側は dialog ID、CSeq、RSeq が同じ再送を捨てる。予想より先の RSeq が届いた場合は PRACK を返さず処理もしない。欠けた番号を待つために保存することはできる。これは「何か届いた」という監視ではなく、順序を含む受領記録である。

64*T1 の間に対応 PRACK がなければ、UAS は元の要求を 5xx で拒否することが推奨される。信頼性を追加すると、タイマー、未確認リスト、経路、認証という新しい故障面も生まれる。仕様は望ましい挙動を示すが、現行製品の実装率や正確さを示す統計ではない。

offer/answer が完了しても INVITE は未完了

PRACK は本文を持てる。INVITE に offer があれば、信頼できる仮応答が answer を運べる。INVITE に offer がなければ、最初の信頼できるメッセージとなる仮応答が offer を出し、PRACK が answer を返す。PRACK が新しい offer を持つ場合は、その 2xx が answer を持つ。

この交換によってセッションのパラメータは最終回答前に成立し得る。それでも INVITE の受諾とは別である。セッション記述を含む信頼できる仮応答が未確認のとき、UAS は INVITE の最終 2xx を、その PRACK が届くまで遅らせなければならない。守られているのは offer/answer の整合であり、PRACK に最終決定権が移ったのではない。

RFC 6337 は、両端が 100rel を使えても全仮応答が信頼できる形になるとは限らないと整理した。offer を含む INVITE に対して、信頼できる非失敗応答の最初の SDP が実際の answer になる。先行する信頼できない 1xx の SDP は予告にとどまる。

RFC 3311 の UPDATE は early dialog と confirmed dialog でパラメータ変更を可能にする。しかし UPDATE、PRACK、INVITE の状態が統合されるわけではない。それぞれに要求、応答、順序があり、運用側は未完了の交換を別々に保持する必要がある。

音声が先に来る場合

RFC 3960 は、呼出音、案内、DTMF などの early media を扱う。SIP 信号とメディアは緩く結合され、異なる経路と時刻で観測される。信号よりメディアが先に現れる場合さえある。

したがって、PRACK は RTP の到達、音声の可聴性、相手の応答を証明しない。音声を聞けたことも、正しい RSeq が RAck で確認された証拠にはならない。二つの時系列は照合すべきだが、片方で他方を代用してはならない。

IANA の SIP Parameters は PRACK、RAck、RSeq、100rel を RFC 3262 と結び付けて登録している。ここから分かるのは正式な割当てであり、導入率や個別装置の適合性ではない。

また、番号の一致は送信者の身元を保証しない。RFC 3262 は、攻撃者が PRACK を注入して重要な仮応答の再送を止める可能性を挙げる。PRACK も他の要求と同様に認証すべきである。状態の一致と信頼できる主体は別の検査項目になる。

出典