この記事は筆者オンリーのAdvent Calendar 20254日目の記事です。
今回は、SIP 通話を維持するための RFC4028（Session Timers） について、できるだけシンプルに解説します。
1. RFC4028（Session Timers）とは？
RFC4028 は、SIP のセッションが 死んでいないか（生きているか）を確認する仕組み を定義した拡張仕様です。
SIP の通話は INVITE → 200 OK → ACK のあと、
SIP レベルでは特に何も送られないまま 長時間続くことがあります。
しかし現実には：
NAT のマッピングが切れる
Proxy / B2BUA の状態が死ぬ
セッションは終わっているのに BYE が来ない
ネットワーク障害で片方向だけ孤立する
など「通話が継続中なのか判断できなくなる」問題が起きがちです。
そこで、RFC4028 は次を提供します：
定期的な “更新（refresh）" を SIP メッセージで行い、
セッションがまだ有効であることを確認する仕組み
これが Session Timer（セッションタイマ） です。
2. Session-Expires と Min-SE
RFC4028 の中心となる SIP ヘッダは以下の 2 つ。
Session-Expires ヘッダ
通話が自動終了するまでの秒数を示す。
例：
Session-Expires: 1800
→ 30分（1800秒）でセッションが expire（期限切れ）
Min-SE ヘッダ
Session Timer の最小値を伝える。
Min-SE: 90
→ タイマ値は最低でも 90 秒以上である必要がある
3. 誰がタイマを更新するのか？（refresher）
RFC4028 では、どちらがセッション更新の責任を持つか を明確にします。
refresher=uac または refresher=uas
例：
Session-Expires: 1800;refresher=uac
→ UAC（発信側）が session refresh（更新）を行う
責任担当（refresher）は
UAS が決めて 200 OK で知らせる
コールフロー中に再交渉も可能
4. Refresh の実体：UPDATE または re-INVITE
Session Timer の更新は：
UPDATE
re-INVITE
のいずれかで行います。
タイマが切れる前に refresher が行う動作
例えば Session-Expires: 1800 の場合：
1800 秒の 半分（900秒）程度で refresh を送るのが一般的
送信例：
UPDATE sip:bob@example.com SIP/2.0
...
または：
INVITE sip:bob@example.com SIP/2.0
これらが 200 OK によって承認されれば、Session Timer はリセットされる。
5. Session Timer を使う実際のメリット
① セッションの消失を検知できる
ネットワーク断・機器故障で片側が死んでも、
refresh が返ってこなければ セッションを自動終了できる。
② NAT マッピングの維持
refresh は SIP レベルのトラフィックなので、
NAT の UDP/TCP 変換が切れにくくなる。
③ 通話課金などの運用要件
「課金のために一定時間で生存確認したい」
というキャリア用途にもマッチ。
6. Session Timer の典型的なコールフロー
最もよく見るパターンは以下：
UA-A (UAC) UA-B (UAS)
| |
|----------- INVITE ---------------->|
|<---------- 200 OK (SE=1800) -------|
|----------- ACK ------------------->|
| |
|--- UPDATE (refresh) -------------->|
|<-- 200 OK -------------------------|
| |
|--- UPDATE (refresh) -------------->|
|<-- 200 OK -------------------------|
| |
|----------- BYE ------------------->|
|<---------- 200 OK -----------------|
ポイント：
refresher はたいてい UAC または UAS のどちらかが担当
refresh が失敗した場合はセッションを切断
更新は UPDATE が一般的（メディアの変更が必要なら re-INVITE）
7. Session Timer が拒否されるケース
UAS が Min-SE を理由に拒否する例：
422 Session Interval Too Small
Min-SE: 120
→ タイマが 120 秒未満なので再送要求
（UAC はより大きな値で INVITE を再送する必要がある）
8. RFC4028 を実装するときの注意点（実践）
① refresher の決定は UAS が主導
業界実装では UAS が refresher=uas を返すことも多い（B2BUA の負荷管理目的）。
② UPDATE を使う方が安全
re-INVITE はメディア協調が必要で面倒なため、
UPDATE で refresh する実装が一般的。
③ Proxy/B2BUA が介在すると必須になる
セッション維持管理を Proxy が行う場合、Session Timer がないと
**セッションリーク（終了できない状態）**が起きやすい。
④ タイマ値は長すぎても短すぎてもダメ
短い → 更新トラフィックが多くなる
長い → セッション消失検知に時間がかかる
実運用では 1800s(30分) 〜 600s(10分) 付近が多い。
9. まとめ
RFC4028 は SIP セッションの生存確認の仕組み
Session-Expires / Min-SE / refresher がキーパラメータ
refresh は UPDATE または re-INVITE
切断検知・NAT維持・通話管理などに必須
実装では UPDATE + refresher=uas がよく使われる