RFC3311 入門：SIP UPDATE メソッドとは何か（re-INVITE との違いも解説）

この記事は筆者オンリーの Advent Calendar 2025
4日目の記事です。
今回は、RFC4028（Session Timer）とも関係が深い RFC3311 / UPDATE メソッドについて、
できるだけシンプルに、実務で役立つ形で解説します。

1. UPDATE メソッドとは？

UPDATE は RFC3311 で定義された SIP の拡張メソッドで、

ダイアログ中に、セッション状態（主に SDP）を更新するための軽量な方法

です。

同じ“セッション更新（refresh）”ができる re-INVITE と目的が似ていますが、UPDATE は：

通話確立前（early dialog）でも使える

100rel（PRACK）と組み合わせて使いやすい

セッションタイマ（RFC4028）の更新に最適

という特徴があり、現代の SIP 実装（IMS/VoLTE など）では re-INVITE より多用されます。

1. UPDATE が必要になるシーン

代表的には以下のケースで利用されます。

① RFC4028（Session Timer）で refresher が UPDATE を送る

前回の記事で書いた Session Timer の refresh に最も使われるのが UPDATE。

UPDATE → 200 OK（Session Timer 更新）

re-INVITE より軽量で、メディア再ネゴシエーションが不要な場合に最適。

② Early Dialog 中に SDP の変更をしたい（通話成立前）

INVITE → 183 Session Progress の後、
着信側が SDP だけ更新したい場合（ICE、アドレス変更など）に UPDATE が使える。

→ re-INVITE は early dialog では使えない（INVITE は1つしか投げられないため）

③ PRACK（RFC3262）と組み合わせて信頼性のある early media を作る

VoLTE / IMS 系では Early Media が重要。
183 + SDP → PRACK → UPDATE（条件更新）という流れがよく登場します。

1. UPDATE と re-INVITE の違い

2つの違いを表で整理するとこうなります。

項目	UPDATE	re-INVITE
仕様	RFC3311	RFC3261
目的	セッション状態の更新	セッションの再ネゴ
Early Dialog で利用	可能	不可
SDP が必要か	任意（なしでも可）	ほぼ必要
トランザクション影響	軽い	重い（INVITE系トランザクション）
UPDATE の典型用途	Session Timer refresh / early media	hold / resume / codec変更など

結論：メディア条件を大きく変えたいなら re-INVITE、
軽量更新や early dialog なら UPDATE が向いている。

1. UPDATE の基本構造

UPDATE リクエスト自体は非常にシンプルです。

UPDATE sip:[e-mail] SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776sgdk
From: <sip:[e-mail]>;tag=8392034
To: <sip:[e-mail]>;tag=98asd7
Call-ID: [e-mail]
CSeq: 2 UPDATE
Contact: <sip:[e-mail]>
Content-Type: application/sdp
Content-Length: 129

v=0
o=alice 2890844526 2890844526 IN IP4 pc33.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

SDP が入らない UPDATE ももちろん可能（Session Timer 用など）。

1. UPDATE を受け取った側の挙動

UPDATE を受信した UAS は、次のように処理します。

ヘッダとダイアログ整合性を確認

SDP がある場合は Offer/Answer を処理

正常なら 200 OK

エラーなら 4xx, 5xx を返す

200 OK の例：

SIP/2.0 200 OK
Via: ...
From: ...
To: ...
Call-ID: ...
CSeq: 2 UPDATE
Content-Length: 0

1. コールフロー例（Session Timer 用 UPDATE）

RFC4028 と組み合わせた最も基本的な UPDATE の流れ。

UA-A (refresher=uac)                  UA-B
     |                                   |
     |--------- INVITE ----------------->|
     |<-------- 200 OK (SE=1800) --------|
     |----------- ACK ------------------->|
     |                                   |
     |---- UPDATE (refresh @900s) ------>|
     |<----------- 200 OK ---------------|
     |                                   |
     |---- UPDATE (refresh @1800s) ----->|
     |<----------- 200 OK ---------------|
     |                                   |
     |------------- BYE ---------------->|
     |<----------- 200 OK ---------------|

UPDATE は軽量で、メディアの renegotiation を伴わないセッション更新に最適。

1. コールフロー例（Early Dialog 中の SDP 更新）

INVITE に対してまだ最終応答が返っていない段階で SDP 変更が必要なケース。

INVITE (OFFER)
↓
183 Session Progress (ANSWER)
↓
UPDATE (OFFER)
200 OK (ANSWER)

re-INVITE では early dialog では使えないため、このような用途は UPDATE の独壇場。

1. UPDATE を実装するときの注意点
   ① UPDATE と re-INVITE の競合を避ける

同時トランザクションは RFC 上 NG。
必ずトランザクション完了後に次を送る。

② SDP が無い UPDATE も OK

Session Timer 用では SDP を含めない UPDATE が基本。

③ UPDATE が 491 (Request Pending) で拒否されるケース

これは UAS 側でまだ前の更新処理が終わっていないときに起きる。
リトライロジックが必要。

④ B2BUA を挟むと UPDATE が片側だけになることがある

SBC / IMS 系では UPDATE を反転・吸収する場合があるため注意。

1. UPDATE が使われないケース

逆に以下のときは re-INVITE を使うべき。

hold / resume

codec を大きく変更する（PCMU → Opus など）

video の追加などメディア条件を大幅に変える場合

UPDATE は軽量更新のためのもので、
メディア協調を伴う場合は re-INVITE が本筋。

1. まとめ

UPDATE は セッション状態を軽量に更新するメソッド

early dialog でも使える点が最大の特徴

Session Timer（RFC4028）と組み合わせると非常に便利

re-INVITE との使い分けが重要

実装では UPDATE が re-INVITE より頻繁に使われる