この記事は筆者オンリーのAdvent Calendar 20256日目の記事です。
今回は SIP の中でも誤解されがちな PRACK（RFC3262） と、
その前提となる 100rel（信頼性ある provisional response） について、
できるだけわかりやすく解説します。
1. PRACK とは何か？
PRACK（Provisional Response Acknowledgement）は、RFC3262 で追加された SIP の拡張で、
1xx（暫定応答）を “信頼性あり” にするための ACK 的なメッセージ
です。
SIP の 1xx（例：180 Ringing / 183 Session Progress）は、
RFC3261 では 信頼性なし（Retransmission されない可能性） でした。
しかし VoLTE / IMS / キャリア系ネットワークでは：
183 + SDP（Early Media）
重要な早期ネゴシエーション
ネットワーク越しの確実な状態伝達
…が必要になり、暫定応答も確実に届けたいという要求が増加。
そこで登場したのが PRACK。
2. なぜ PRACK が必要なのか？（信頼性なし1xxの問題）
RFC3261 の暫定応答は以下の性質があります：
再送は必須ではない
到達保証がない
Proxy/B2BUA の TRANSACTION は 1xx を追跡しない
結果として：
📌 183 Session Progress（SDP付き）が落ちると、大問題になる
Early Media が開かない
アラート音が流れない
ネゴシエーションが崩壊する
ユーザが「着信しない」と感じるケースも
こうした問題を解決するのが 100rel と PRACK のペアです。
3. 100rel とは？（Require / Supported の意味）
RFC3262 の仕組みは 100rel というオプションタグで制御されます。
Supported: 100rel
Require: 100rel
UAC が 100rel をサポートしていることを示す：
Supported: 100rel
UAS が 100rel を必須にする：
Require: 100rel
→ この INVITE に対する 1xx（183など）は PRACK 必須となる。
4. PRACK のコールフロー（基本パターン）
典型的には以下の流れです：
UAC UAS
|-------------- INVITE ---------------->|
|<---- 183 Session Progress (RSeq) -----|
|-------------- PRACK ----------------->|
|<-------------- 200 OK ----------------|
| |
|<-------------- 200 OK ----------------|
|-------------- ACK ------------------->|
重要なポイント：
✔ 183 などの 1xx に RSeq（Reliable Sequence Number） が含まれる
例：
RSeq: 1
Require: 100rel
✔ UAC は RSeq を参照して PRACK を送る
PRACK sip:bob@example.com SIP/2.0
RAck: 1 314159 INVITE
RAck:
RSeq → 1xx の識別子
CSeq → INVITE の CSeq
method → INVITE（固定）
✔ UAS は PRACK に対して 200 OK を返す
ここで初めて、その 1xx が 信頼的に届いたことが確定 する。
5. PRACK + UPDATE が IMS / VoLTE で必須な理由
キャリア網では Early Media や SDP の複数段階更新が必要になることが多く：
INVITE
↓
183 (SDP)
↓ PRACK
UPDATE (SDP再ネゴ)
↓ 200 OK
という動きが一般的。
PRACK の役割は「early dialog の同期点を作る」こと。
PRACK が返ってくるまで、UAS は次の暫定応答（別 RSeq）は送れない。
6. 実際の SIP メッセージ例
1xx（信頼性あり暫定応答）
SIP/2.0 183 Session Progress
Via: ...
To: ...
From: ...
Call-ID: ...
CSeq: 314159 INVITE
Require: 100rel
RSeq: 1
Content-Type: application/sdp
...
PRACK
PRACK sip:bob@example.com SIP/2.0
Via: ...
To: ...
From: ...
Call-ID: ...
CSeq: 314160 PRACK
RAck: 1 314159 INVITE
Content-Length: 0
PRACK に対する 200 OK
SIP/2.0 200 OK
Via: ...
From: ...
To: ...
Call-ID: ...
CSeq: 314160 PRACK
Content-Length: 0
7. RSeq / RAck の関係
PRACK の本質はここに集約される：
UAS → RSeq（1xx識別番号）
UAC → RAck（受領確認＋対応するINVITEのCSeq）
RSeq は 32bit、連番でなくてもよいが 単調増加 が必要。
UAS は PRACK が返るまで 次の RSeq を送れない制約がある。
8. PRACK を使うときの注意点
① 1xx は「RAck が返るまでロック」される
並行する RSeq の発行は不可。
② PRACK はトランザクション的には ACK とは全く別物
ACK は INVITE の最終応答用、
PRACK は 暫定応答 用。
③ re-INVITE や UPDATE との並行処理は制御が難しい
IMS はここを厳密に規定している（TS24.229）。
④ Require: 100rel を返した場合、UAS は PRACK を必ず待つ
→ PRACK を待たずに 200 OK（INVITE）を返してはいけない。
9. PRACK が不要なケース
場合によっては PRACK を使わない方が良い：
普通の VoIP（PBX → UA）のみの場合
早期メディアが不要な場合
信頼性なしの 180/183 でも問題ないローカル環境
ほとんどの「家庭用 SIP 端末」は PRACK を使わない。
10. まとめ
PRACK は 信頼性ある1xx応答を実現するための仕組み
100rel（Require / Supported）が鍵
183 + SDP を確実に届けるために必須
IMS / VoLTE では必須の動作
RSeq（送信側）と RAck（受信側）の対応が本質
Early Media や UPDATE と非常に相性が良い