<p><!--META { "title": "SIP (RFC 3261) INVITEダイアログのプロトコル設計と実装", "primary_category": "ネットワークプロトコル", "secondary_categories": ["VoIP", "SIP", "RFC"], "tags": ["SIP", "RFC3261", "INVITE", "VoIP", "通信プロトコル", "ダイアログ", "トランザクション"], "summary": "RFC 3261に基づくSIP INVITEダイアログのプロトコル設計と実装について、主要なメッセージフロー、トランザクション管理、セキュリティ対策、および実装時の注意点を解説します。", "mermaid": true, "verify_level": "L0", "tweet_hint": {"text":"SIP (RFC 3261) INVITEダイアログの設計と実装を解説。メッセージフロー、トランザクション、セキュリティ、実装注意点を網羅。ネットワークエンジニア必見！ #SIP #RFC3261 #VoIP","hashtags":["#SIP","#RFC3261"]}, "link_hints": ["https://datatracker.ietf.org/doc/html/rfc3261", "https://datatracker.ietf.org/doc/html/rfc8599"] } --> 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">SIP (RFC 3261) INVITEダイアログのプロトコル設計と実装</h1> <h2 class="wp-block-heading">背景</h2> <p>Session Initiation Protocol (SIP) は、VoIP (Voice over IP) やその他のマルチメディア通信セッションの確立、変更、終了を目的としたシグナリングプロトコルです。その中でも <code>INVITE</code> メソッドは、通信セッションを開始するための最も基本的な要素であり、SIPの心臓部とも言えます。SIPはRFC 3261 [1] で標準化されており、その詳細な仕様が定義されています。</p> <p>ネットワークエンジニアとしてSIPプロトコルを実装、運用する際には、<code>INVITE</code> ダイアログの挙動を深く理解することが不可欠です。これには、メッセージフロー、状態遷移、信頼性メカニズム、そしてセキュリティ考慮事項が含まれます。</p> <h2 class="wp-block-heading">設計目標</h2> <p>SIP <code>INVITE</code> ダイアログの設計は、以下の主要な目標を達成することを目指しています。</p> <ul class="wp-block-list"> <li><p><strong>状態管理とセッション確立</strong>: 通信セッションの確立に必要な情報（メディア形式、IPアドレス、ポートなど）を交換し、対話の状態を一貫して維持すること。</p></li> <li><p><strong>信頼性</strong>: 不安定なネットワーク環境下でも、セッション確立メッセージの到達を保証するための再送メカニズムを提供すること。</p></li> <li><p><strong>柔軟性</strong>: さまざまな通信形態（音声通話、ビデオ会議、インスタントメッセージなど）やネットワークトポロジ（NAT越え、プロキシ経由など）に対応できる柔軟性を持つこと。</p></li> <li><p><strong>拡張性</strong>: 将来的な新しいサービスや機能追加に容易に対応できるような拡張ポイントを提供すること。</p></li> </ul> <h2 class="wp-block-heading">詳細</h2> <h3 class="wp-block-heading">ダイアログとトランザクション</h3> <p>SIPにおいて、「トランザクション」と「ダイアログ」は異なる概念であり、<code>INVITE</code> メソッドにおいて両者が密接に関わります。</p> <ul class="wp-block-list"> <li><p><strong>トランザクション</strong>: 1つのリクエストと、それに対応する1つ以上のレスポンスの交換を指します。<code>INVITE</code> メソッドは独自のトランザクションタイプを持ち、信頼性を確保するための再送ロジックを含みます [1, Section 13, 14]。</p></li> <li><p><strong>ダイアログ</strong>: 2つのUser Agent (UA) 間の永続的なピアツーピアの関係を指します。これは <code>Call-ID</code>、<code>From</code> ヘッダの <code>tag</code> パラメータ、および <code>To</code> ヘッダの <code>tag</code> パラメータの組み合わせによって一意に識別されます [1, Section 12, 17]。<code>INVITE</code> メソッドが2xx応答を受け取り、ACKで確認されると、ダイアログが確立されます。このダイアログはセッションの終了 (<code>BYE</code>) まで維持されます。</p></li> </ul> <h3 class="wp-block-heading">INVITEダイアログのメッセージフロー</h3> <p>基本的な <code>INVITE</code> ダイアログの確立プロセスは以下のシーケンスで表現できます。UAC (User Agent Client) が <code>INVITE</code> を送信し、UAS (User Agent Server) が応答します。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> sequenceDiagram participant UAC as 発信元UA participant ProxyServer as プロキシサーバ participant UAS as 着信先UA UAC ->> ProxyServer: INVITE Request |SDP (メディア情報)| ProxyServer ->> UAS: INVITE Request |SDP (メディア情報)| Note over UAS: セッション確立処理開始 UAS -->> ProxyServer: 100 Trying |(処理中)| ProxyServer -->> UAC: 100 Trying |(処理中)| Note over UAS: 着信呼び出し中 UAS -->> ProxyServer: 180 Ringing |(呼び出し中)| ProxyServer -->> UAC: 180 Ringing |(呼び出し中)| alt UASが応答した場合 UAS -->> ProxyServer: 200 OK |SDP (最終的なメディア情報)| ProxyServer -->> UAC: 200 OK |SDP (最終的なメディア情報)| Note over UAC: セッション確立完了、ACKを送信 UAC ->> ProxyServer: ACK Request ProxyServer ->> UAS: ACK Request Note over UAC,UAS: セッション開始（RTPなど） else UASが拒否した場合 (例:話中) UAS -->> ProxyServer: 486 Busy Here |(話中)| ProxyServer -->> UAC: 486 Busy Here |(話中)| Note over UAC: セッション確立失敗、ACKを送信 UAC ->> ProxyServer: ACK Request ProxyServer ->> UAS: ACK Request Note over UAC,UAS: セッション確立失敗 end </pre></div> <p><strong>再送メカニズム</strong>: UDPトランスポートを使用する場合、<code>INVITE</code> リクエストの信頼性はクライアントトランザクションによって担保されます。UACは <code>INVITE</code> を送信後、1xx応答が指定時間 <code>T1</code> (デフォルト500ms) 以内に受信されなければ、<code>INVITE</code> を再送します。再送タイマーは指数的に増加し、最大 <code>T2</code> (デフォルト4秒) まで、または合計 <code>T4</code> (デフォルト32秒) の間再送を試みます。これにより、ネットワークのパケットロスがあってもセッション確立の可能性を高めます [1, Section 13.3.1]。</p> <h3 class="wp-block-heading">INVITEトランザクションの状態遷移</h3> <p>SIP <code>INVITE</code> トランザクションは、クライアント側 (UAC) とサーバ側 (UAS) でそれぞれ状態を管理します。ここではUAC側の主要な状態遷移を簡略化して示します。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> flowchart TD ID0[Idle] --> ID1[Calling] ID1 --|INVITE送信| ID1 ID1 --|1xx受信| ID2[Proceeding] ID1 --|2xx受信| ID3[Confirmed] ID1 --|3xx-6xx受信| ID4[Completed] ID1 --|T1/T2/T4タイムアウト| ID5[Terminated] ID2 --|1xx受信| ID2 ID2 --|2xx受信| ID3 ID2 --|3xx-6xx受信| ID4 ID2 --|T1/T2/T4タイムアウト| ID5 ID3 --|ACK送信| ID5 ID3 --|タイマー経過 (ACK再送待機)| ID5 ID4 --|ACK送信| ID5 ID4 --|タイマー経過 (ACK再送待機)| ID5 ID5 --|トランザクション終了| ID0 </pre></div> <ul class="wp-block-list"> <li><p><strong>Idle</strong>: トランザクションが開始されていない状態。</p></li> <li><p><strong>Calling</strong>: <code>INVITE</code> リクエストが送信され、応答を待っている状態。1xx、2xx、3xx-6xx応答、またはタイマータイムアウトによって次の状態へ遷移します。</p></li> <li><p><strong>Proceeding</strong>: 1xx (provisional response) が受信され、最終応答を待っている状態。</p></li> <li><p><strong>Confirmed</strong>: 2xx (successful final response) が受信され、UACが <code>ACK</code> を送信した後の状態。再送された2xxを受け取る可能性があるため、短期間維持されます。</p></li> <li><p><strong>Completed</strong>: 3xx-6xx (unsuccessful final response) が受信され、UACが <code>ACK</code> を送信した後の状態。再送された最終応答を受け取る可能性があるため、短期間維持されます。</p></li> <li><p><strong>Terminated</strong>: トランザクションが終了した状態。</p></li> </ul> <h3 class="wp-block-heading">主要ヘッダフィールドの構造</h3> <p>SIPメッセージはテキストベースであり、HTTPに似たヘッダ構造を持ちます。以下に <code>INVITE</code> リクエストの主要なヘッダフィールドとその役割を示します。ビット長ではなく、フィールドの役割と内容の形式で表現します。</p> <div class="codehilite"> <pre data-enlighter-language="generic">INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds (経由したSIPエンティティのプロトコル、ホスト、ポート、およびbranchパラメータ) Max-Forwards: 70 (リクエストが転送される最大ホップ数) From: Alice <sip:alice@example.com>;tag=1928301774 (発信元の表示名、URI、およびダイアログ識別用のタグ) To: Bob <sip:bob@example.com> (着信先の表示名、URI。ダイアログ確立後にタグが追加される) Call-ID: a84b4c76e66710@pc33.example.com (ダイアログを一意に識別するID) CSeq: 314159 INVITE (リクエストのシーケンス番号とメソッド名。ダイアログ内で増分) Contact: <sip:alice@pc33.example.com> (発信元UAの直接的な連絡先URI) Content-Type: application/sdp (メッセージボディのメディアタイプ、通常はSDP) Content-Length: 142 (メッセージボディのバイト長) </pre> </div> <h2 class="wp-block-heading">相互運用性</h2> <p>SIPは他の多くのプロトコルと連携して機能します。</p> <ul class="wp-block-list"> <li><p><strong>HTTP/1.1 との比較</strong>:</p> <ul> <li><p><strong>類似点</strong>: テキストベースのメッセージ、ヘッダ/ボディ構造、ステータスコード、URIの使用など、SIPはHTTP/1.1から多くの概念を継承しています。</p></li> <li><p><strong>相違点</strong>: SIPは状態を保持する「ダイアログ」の概念を持つ点でHTTPとは大きく異なります。HTTPがステートレスなリクエスト/レスポンスであるのに対し、SIPはセッション管理のためにダイアログの状態を維持します。また、SIPはセッション確立・変更・終了に特化しており、トランスポートはUDP/TCPの両方を使用します。</p></li> </ul></li> <li><p><strong>HTTP/2, HTTP/3 との比較</strong>:</p> <ul> <li><p><strong>HTTP/2 (SPDY由来)</strong>: 多重化ストリーム、ヘッダ圧縮、サーバプッシュなどにより、単一TCP接続での効率を向上させます。SIPはこのような多重化機構を持たず、メッセージは個別に処理されます。</p></li> <li><p><strong>HTTP/3 (QUICベース)</strong>: UDP上で動作し、TCPのHOLブロッキングを回避し、接続確立を高速化します。SIPはUDPを主要なトランスポートとして利用しますが、HOLブロッキングの回避はアプリケーションレベルでの工夫が必要です。SIP自体はQUICのような機能は持っていません。</p></li> </ul></li> <li><p><strong>RTP (Real-time Transport Protocol) との連携</strong>:</p> <ul> <li><p>SIPはシグナリングプロトコルであり、メディアストリーム自体を伝送しません。メディアストリームは通常、RTP/RTCP (Real-time Transport Control Protocol) によって伝送されます。</p></li> <li><p>SIP <code>INVITE</code> リクエストのボディには、通常SDP (Session Description Protocol) が含まれ、RTPセッションの確立に必要な情報（使用するコーデック、IPアドレス、ポート番号など）を交換します。</p></li> </ul></li> </ul> <h2 class="wp-block-heading">セキュリティ考慮</h2> <p>SIP通信は、多くのセキュリティ上の脅威にさらされる可能性があります。</p> <ul class="wp-block-list"> <li><p><strong>リプレイ攻撃 (Replay Attacks)</strong>: 以前傍受した認証情報を再利用して不正なアクセスを試みる攻撃。SIPではDigest認証（RFC 2617に基づき、RFC 8599 [4] で改善されたもの）が広く利用され、<code>nonce</code> 値を用いることでリプレイ攻撃を軽減します。</p></li> <li><p><strong>ダウングレード攻撃 (Downgrade Attacks)</strong>: よりセキュアなプロトコルを強制的にダウングレードさせ、脆弱なプロトコルを使用させる攻撃。SIPでは、SIPS URIの使用や、TLS (Transport Layer Security) の必須化により、セキュアでないトランスポートへのダウングレードを防ぐべきです [1, Section 26.2.2]。</p></li> <li><p><strong>キー更新 (Key Update)</strong>: メディアの暗号化に利用されるキーは定期的に更新されるべきです。これはSRTP (Secure Real-time Transport Protocol) やSDPの<code>a=key-mgmt</code>属性などを通じて行われます。</p></li> <li><p><strong>0-RTTのリスク</strong>: SIPの初期<code>INVITE</code>は、TLS 1.3のような「0-RTT」確立を直接サポートするものではありません。SIPトランザクションは通常、複数のラウンドトリップを必要とします。仮に初期メッセージで認証情報などを事前共有する仕組みを導入した場合、リプレイ攻撃のリスクが高まる可能性があります。SIPでは、認証とセッション確立は通常、少なくとも1回以上のチャレンジ/レスポンスを経て行われます。</p></li> <li><p><strong>DoS攻撃 (Denial of Service Attacks)</strong>: 大量の不正な <code>INVITE</code> リクエストを送信し、SIPプロキシやUAのリソースを枯渇させる攻撃。レートリミット、不正なIPアドレスのブロック、厳格なメッセージ検証により対処が必要です [1, Section 26.1]。</p></li> <li><p><strong>盗聴と改ざん</strong>: SIPメッセージやメディアストリームの盗聴、およびメッセージの改ざん。SIPS URIとTLSを使用することで、シグナリングメッセージの機密性と完全性を保護できます。メディアストリームにはSRTPを使用します [1, Section 26.2.2]。</p></li> </ul> <h2 class="wp-block-heading">実装メモ</h2> <p>SIP <code>INVITE</code> ダイアログを実装する上で、ネットワークエンジニアが考慮すべき点は多岐にわたります。</p> <ul class="wp-block-list"> <li><p><strong>MTU / Path MTU</strong>: SIPメッセージ（特にSDPを含む <code>INVITE</code>）はUDPで送信される場合、IP層でのフラグメンテーションを避けるため、MTU（最大転送単位）を考慮する必要があります。Path MTU Discovery (PMTUD) を利用して最適なMTUを見つけるか、TCPトランスポートを検討します。</p></li> <li><p><strong>HOL blocking 回避</strong>: TCPを使用する場合、ヘッダラインブロッキング (Head-of-Line blocking) が発生する可能性があります。SIPメッセージは通常小さく、多重化は不要ですが、TCP接続を多重利用するシナリオでは、アプリケーションレベルでのメッセージキューイングや並列処理を検討する必要があります。UDPではこの問題は発生しませんが、再送処理はアプリケーション層で実装が必要です。</p></li> <li><p><strong>キュー制御と優先度</strong>: SIPプロキシやUAは、大量の <code>INVITE</code> リクエストを同時に処理する可能性があります。重要なシグナリングメッセージ（<code>INVITE</code>, <code>BYE</code> など）と、セッション内の<code>REFER</code>などのメッセージに対して適切なキュー制御と優先度付けを行い、システムのスループットと応答性を維持することが重要です。</p></li> <li><p><strong>タイマー管理</strong>: SIPトランザクションは、RFC 3261で定義されている多くのタイマー (T1, T2, T4, G, H, I, J, Kなど) を正確に実装する必要があります [1, Section 13.3.1]。これにより、メッセージの再送、トランザクションのタイムアウト、ダイアログのライフサイクルが正しく管理されます。特に、UDPトランスポートにおける再送ロジックは実装の鍵となります。</p></li> <li><p><strong>NAT/ファイアウォール越え</strong>: SIPはNAT (Network Address Translation) やファイアウォールの透過性に課題を抱えています。<code>Contact</code> ヘッダやSDPのIPアドレス情報がプライベートアドレスの場合、STUN/TURN/ICEなどの技術を組み合わせて、セッション確立を可能にする必要があります。</p></li> </ul> <h2 class="wp-block-heading">まとめ</h2> <p>SIP (RFC 3261) の <code>INVITE</code> ダイアログは、VoIPやリアルタイム通信の中核をなすプロトコルです。その設計は、トランザクションとダイアログという二つの重要な概念に基づき、信頼性と柔軟性を提供します。実装においては、メッセージフロー、状態遷移、再送メカニズムの正確な理解が不可欠です。また、セキュリティ脅威への対策（認証、暗号化、DoS対策）と、ネットワーク環境（MTU、NAT）を考慮した実装は、堅牢な通信システムを構築するために極めて重要です。</p> <hr/> <p><strong>参照:</strong> [1] J. Rosenberg et al., “SIP: Session Initiation Protocol”, RFC 3261, June 2002. <a href="https://datatracker.ietf.org/doc/html/rfc3261">https://datatracker.ietf.org/doc/html/rfc3261</a> (2002年6月公開, IETF) [2] A. B. Roach, “Session Initiation Protocol (SIP) Specific Event Notification”, RFC 3265, June 2002. <a href="https://datatracker.ietf.org/doc/html/rfc3265">https://datatracker.ietf.org/doc/html/rfc3265</a> (2002年6月公開, IETF) [3] A. B. Roach et al., “SIP-Specific Event Notification”, RFC 6665, July 2012. <a href="https://datatracker.ietf.org/doc/html/rfc6665">https://datatracker.ietf.org/doc/html/rfc6665</a> (2012年7月公開, IETF) [4] D. Wing, H. Kaplan, “SIP Digest Authentication Improvements”, RFC 8599, June 2019. <a href="https://datatracker.ietf.org/doc/html/rfc8599">https://datatracker.ietf.org/doc/html/rfc8599</a> (2019年6月公開, IETF) [5] IETF SIP Working Group Status. <a href="https://datatracker.ietf.org/wg/sip/about/">https://datatracker.ietf.org/wg/sip/about/</a> (2024年7月29日最終更新, IETF)</p>

sequenceDiagram
    participant UAC as 発信元UA
    participant ProxyServer as プロキシサーバ
    participant UAS as 着信先UA

    UAC ->> ProxyServer: INVITE Request |SDP (メディア情報)|
    ProxyServer ->> UAS: INVITE Request |SDP (メディア情報)|
    Note over UAS: セッション確立処理開始
    UAS -->> ProxyServer: 100 Trying |(処理中)|
    ProxyServer -->> UAC: 100 Trying |(処理中)|
    Note over UAS: 着信呼び出し中
    UAS -->> ProxyServer: 180 Ringing |(呼び出し中)|
    ProxyServer -->> UAC: 180 Ringing |(呼び出し中)|
    alt UASが応答した場合
        UAS -->> ProxyServer: 200 OK |SDP (最終的なメディア情報)|
        ProxyServer -->> UAC: 200 OK |SDP (最終的なメディア情報)|
        Note over UAC: セッション確立完了、ACKを送信
        UAC ->> ProxyServer: ACK Request
        ProxyServer ->> UAS: ACK Request
        Note over UAC,UAS: セッション開始（RTPなど）
    else UASが拒否した場合 (例:話中)
        UAS -->> ProxyServer: 486 Busy Here |(話中)|
        ProxyServer -->> UAC: 486 Busy Here |(話中)|
        Note over UAC: セッション確立失敗、ACKを送信
        UAC ->> ProxyServer: ACK Request
        ProxyServer ->> UAS: ACK Request
        Note over UAC,UAS: セッション確立失敗
    end

flowchart TD
    ID0[Idle] --> ID1[Calling]
    ID1 --|INVITE送信| ID1
    ID1 --|1xx受信| ID2[Proceeding]
    ID1 --|2xx受信| ID3[Confirmed]
    ID1 --|3xx-6xx受信| ID4[Completed]
    ID1 --|T1/T2/T4タイムアウト| ID5[Terminated]

    ID2 --|1xx受信| ID2
    ID2 --|2xx受信| ID3
    ID2 --|3xx-6xx受信| ID4
    ID2 --|T1/T2/T4タイムアウト| ID5

    ID3 --|ACK送信| ID5
    ID3 --|タイマー経過 (ACK再送待機)| ID5

    ID4 --|ACK送信| ID5
    ID4 --|タイマー経過 (ACK再送待機)| ID5

    ID5 --|トランザクション終了| ID0

INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
    (経由したSIPエンティティのプロトコル、ホスト、ポート、およびbranchパラメータ)
Max-Forwards: 70
    (リクエストが転送される最大ホップ数)
From: Alice <sip:alice@example.com>;tag=1928301774
    (発信元の表示名、URI、およびダイアログ識別用のタグ)
To: Bob <sip:bob@example.com>
    (着信先の表示名、URI。ダイアログ確立後にタグが追加される)
Call-ID: a84b4c76e66710@pc33.example.com
    (ダイアログを一意に識別するID)
CSeq: 314159 INVITE
    (リクエストのシーケンス番号とメソッド名。ダイアログ内で増分)
Contact: <sip:alice@pc33.example.com>
    (発信元UAの直接的な連絡先URI)
Content-Type: application/sdp
    (メッセージボディのメディアタイプ、通常はSDP)
Content-Length: 142
    (メッセージボディのバイト長)