要約

  • RFC 4028で有効期限を延長するのは、セッション更新用のre-INVITEまたはUPDATEに対する2xxだけである。送信、422、経路上での観測は成功の代わりにならない。
  • Session-Expires、Min-SE、refresherは更新頻度と担当、状態削除の境界を定める。RTP到達、利用者の在席、品質、同意、課金の正当性は証明しない。
  • 取引、ダイアログ、メディア、アプリ、人、商取引の証拠を分けたまま関連付けることで、初めて「通話が生きている」という判断を再構成できる。

更新は成功、音声は不通

通話状態を保持するSIPプロキシがあり、RTPは別経路を通る。割り当てられた更新側は、間隔の半分ほどでSDPを持たないUPDATEを送る。対向UAは200 OKを返す。プロキシは自分の失効時刻を先へ送る。

同時にメディア経路では片方向障害が起きている。RTPカウンタは止まり、RTCP受信報告も来ない。端末のソフトウェアは更新を続けるが、人はもう会話に参加していない。課金が成功した更新だけを見るなら、提供されていない時間まで請求対象になり得る。

RFC 4028の目的は、こうした全てを一つの真偽値で決めることではない。UAがBYEを送らない、またはBYEが失われると、状態を持つプロキシは呼の終了を知れず、資源を保持し続ける。周期的なre-INVITEやUPDATEと失効規則は、そのSIP状態に上限を与える。

規格は音声固有の生存指標としてRTCPにも触れ、SIPレベルの生存をメディアの詳細から分ける。つまり、違う層に違う問いを割り当てる設計である。

一つの期間に見える三つの量

セッション間隔は、成功した更新と次の成功した更新の間に許される最大時間である。最新の2xxにあるSession-Expiresが基準になる。

最小タイマーは、その要素が受け入れられる最短間隔である。ダイアログ内要求は処理負荷を生むため、Min-SEは過度な更新頻度を防ぐ。

セッション失効は各要素がローカルに計算する締切である。UASは2xx送信時刻、UACは受信時刻、プロキシは自分が応答を処理した時刻から計算する。経路遅延がある以上、全員が共有する一つの署名済み時刻ではない。

障害分析では、間隔値だけでなく、その値を確定した応答、送受信時刻、担当、各要素の締切を保存する必要がある。壁時計の変化に耐えるローカルな単調時計と、後から照合できるイベント時刻の両方が望ましい。

経路が上下限を作る

初期UACはtimer対応を示し、希望するSession-Expiresを提案できる。呼状態を保持するプロキシもタイマーを要求し、上限を短くしたりMin-SEを引き上げたりできる。ただし蓄積した最小値より短い間隔を強制できない。

UASは2xxに最終値とrefresherを入れる。戻り経路のプロキシは最終値を観測するが、さらに変更してはならない。

提案が短すぎれば、要素は422 Session Interval Too SmallとMin-SEを返す。UACはCSeqを増やした新しい取引で再試行し、関係する最大の最小値を引き継ぐ。

422は交渉であって更新成功ではない。現在の締切は動かない。失効直前の422は、将来の間隔を長くするよう求めながら、現在の再試行にはほとんど時間を残さないことがある。後の200だけを数えると、その危険な窓が消える。

Min-SEは負荷攻撃への防壁でもある。422増加は経路変更、方針変更、過負荷防止、設定不良、悪意のいずれでも起こり得る。コードだけで原因を決めてはならない。

uacは「発信者」という名前ではない

refresher=uacまたはrefresher=uasは、次の更新を誰が送るかを示す。UAC/UASはその取引における役割であり、永続的な発信者、契約者、人の身元ではない。

最初のINVITEを受けた側も、後でUPDATEを送れば新しいUACになる。後続要求では、取引上の役割が反転しても実際の更新担当を維持できるようパラメータを扱う。

ログにuacだけを残すと、責任主体を誤認する。ダイアログ、メソッド、CSeq、方向と合わせて、その取引の具体的エンドポイントへ解決しなければならない。

フォークでは一つのINVITEから複数ダイアログが生じ、それぞれ異なる間隔、担当、失効、あるいはタイマーなしを持てる。一枝の更新は別の枝を更新しない。

また、後の交渉で担当を変えられる。最新の2xxにSession-Expiresがなければ、ダイアログ途中でタイマーが無効になる。「開始時に有効だった」という履歴は現状証明ではない。

締切を動かす唯一の結果

RFC 4028は2xxだけが失効を延長すると定める。

UPDATEを送ったこと、暫定応答、401/407、422、ソケット書き込み成功、プロキシが要求を見たことは延長ではない。認証後の再試行が成功すれば、その2xxが初めて効果を持つ。

更新取引がタイムアウトするか408/481を返せば、更新側UAはBYEを送る。他の失敗には限定的な再試行があり得るが、同じエラーを無限に繰り返すべきではない。

待つ側は、更新が来なければ自分の失効より少し前にBYEを送る。推奨の先行時間は32秒と間隔の3分の1の小さい方である。期限ちょうどではファイアウォールやNAT ALGがSIPを通さない恐れがあるためだ。

プロキシの権限はさらに狭い。期限を過ぎたら自分の呼状態と資源を削除できるが、BYEを送ってはいけない。中間台帳を掃除する権限と、端末として会話を終える権限は別である。

したがって、プロキシは状態を失い、直結メディアは続く場合がある。BYEは送られても失われる。送信時刻と受信時刻に基づく締切は完全一致しない。運用記録は、その差を一つの架空の終了時刻に丸めるべきではない。

更新要求は空の脈拍ではない

タイマー更新に使うre-INVITEやUPDATEは通常のSIP要求である。RFC 3311のUPDATEはセッション情報とリモートターゲットを変え得る。RFC 3261のre-INVITEもダイアログ、ターゲット、offer/answer規則に従う。

純粋な更新では、相手が対応するならofferなしUPDATEが推奨される。re-INVITEはセッション記述が変わらなくても通常offerを持ち、変更なしを正しく表現する必要がある。別目的の要求がタイマーも更新することもある。

同じ2xxが、タイマー延長と同時にContact変更、SDP交換、hold、ストリーム方向、アドレス、コーデック変更を伴うことがある。RFC 6141がre-INVITE競合、491、状態復元、ターゲット更新を扱うのは、それが単純なheartbeatではないからだ。

監査では、timerだけを目的としたか、SDPを含んだか、origin versionや方向が変わったか、Contactが変わったか、どの最終応答で完了したかを残す。

メディアは別の現実を持つ

RFC 3264では、ストリームをsendonly、recvonly、sendrecv、inactive、またはport zeroで拒否として交渉できる。これは許容される状態の記述であり、パケット受領証ではない。

RFC 3550はRTPが配送やQoSを保証しないと明記する。RTCPは受信報告、同期、参加情報を与えるが、人が聞いた、同意した、価値を得たことまでは証明しない。

少なくとも、SIP取引、ダイアログとタイマー、RTP/RTCP、アプリと人、契約・課金・コンプライアンスを分ける。2xxは前二つには強い。後三つには独立した証拠が要る。

シグナリング更新中にメディアが死ぬことも、SIP分断中にメディアが続くこともある。inactiveは正常状態になり得る。人がいなくてもソフトは更新できる。

Heng Luの現実層の考え方を適用すると、整った記録を否定せず、その記録が実行層を支配しないようにできる。運ぶ、測る、課金する、復旧する各システムは、自分の決定を他層へ委任できない。

ホップごとの保護とその限界

タイマー項目はプロキシが正当に変更するため、エンドツーエンドS/MIMEは適さない。RFC 4028は関連する各ホップのTLSとSIPSを推奨する。

全ホップが守られれば、外部者が間隔を短縮し負荷を増幅する危険を減らせる。それでも保護された値はタイマー方針であり、人や課金の証明ではない。

RFC 4028のErrataには検証済みの用語・例修正と未確定の提案がある。2026年5月のReported項目は、明示的refresher=uas希望をプロキシがどう扱うかを論じる。相互接続試験の対象にはなるが、改訂済み規範として扱ってはならない。

争いに耐える記録

Call-IDと両tagを、各取引の実エンドポイント役割へ結ぶ。メソッド、CSeq、branch、route、各ホップ前後のタイマー値、送受信時刻、ローカル締切、決定的2xxを保存する。

SDPの有無とハッシュ、offer/answer version、方向、Contact、認証challengeと再試行も保存する。BYEには、人の操作、更新失敗、相手待ち失効、アプリ方針という発生理由を付ける。

メディア、アプリ、課金は独立した証拠として関連付ける。SIP原文は身元とトポロジーを含むため、一般メトリクスには鍵付きハッシュや投影を使い、原文は制限された事故証拠に置く。

422が期限直前に来る場合、401後の成功、408/481、待ち側の失効、BYEなしのプロキシ削除、メディア障害中の更新、SIP障害中のメディア、異なるfork、timer無効化、offerなしUPDATE、SDP変更re-INVITE、target refresh、failover、未保護ホップを試験する。

必要なのは「active」という一語ではない。どの層が続き、どの根拠で誰が動いたかを説明できる時間軸である。

出典