<p><!--META
{
"title": "SIP (Session Initiation Protocol)の基本解説 - RFC 3261準拠",
"primary_category": "ネットワーク>プロトコル",
"secondary_categories": ["VoIP", "リアルタイム通信"],
"tags": ["SIP", "RFC3261", "VoIP", "RTP", "SDP", "リアルタイム通信"],
"summary": "SIP (Session Initiation Protocol)の基本概念、アーキテクチャ、メッセージ構造、セキュリティ、実装上の注意点をRFC 3261に基づき解説します。",
"mermaid": true,
"verify_level": "L0",
"tweet_hint": {"text":"SIP (Session Initiation Protocol)について、RFC 3261に基づいた基本解説をまとめました。VoIPやリアルタイム通信の基盤となるプロトコルの動作原理、セキュリティ、実装上のポイントを図解で理解できます。","hashtags":["#SIP","#RFC3261","#VoIP"]},
"link_hints": ["https://datatracker.ietf.org/doc/html/rfc3261"]
}
-->
本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p>
<h1 class="wp-block-heading">SIP (Session Initiation Protocol)の基本解説 – RFC 3261準拠</h1>
<h2 class="wp-block-heading">背景</h2>
<p>Session Initiation Protocol (SIP) は、VoIP（Voice over IP）やマルチメディア通信において、セッションの確立、変更、終了を制御するためのアプリケーション層のシグナリングプロトコルです。インターネット上でのリアルタイム通信の基盤として広く採用されており、HTTPに類似したテキストベースのメッセージングとクライアント-サーバモデルを特徴とします。</p>
<p>SIPは、IETFによって標準化されており、その主要な仕様は2002年6月に発行されたRFC 3261「SIP: Session Initiation Protocol」に定義されています[1]。このプロトコルは、メディアセッション自体を転送するのではなく、参加者のアドレス解決、能力ネゴシエーション、セッション確立、セッション管理（一時停止、転送、終了など）といった「シグナリング」を担当します。実際のメディアデータ（音声やビデオなど）の転送には、通常、Real-time Transport Protocol (RTP) が用いられ、セッションの内容（コーデック、ポート番号など）はSession Description Protocol (SDP) で記述されます[4]。</p>
<h2 class="wp-block-heading">設計目標</h2>
<p>RFC 3261に記載されているSIPの主な設計目標は以下の通りです[1]:</p>
<ul class="wp-block-list">
<li><p><strong>参加者の特定と位置特定</strong>: ユーザーを特定し、その現在のネットワークアドレスを解決するメカニズムを提供します。</p></li>
<li><p><strong>参加者の能力ネゴシエーション</strong>: 通信セッションで利用可能なメディアタイプ、コーデック、その他のパラメータを交換し、合意するための手段を提供します。</p></li>
<li><p><strong>セッションの確立と管理</strong>: セッションの開始、中断、再開、変更、終了といったライフサイクル全体を管理します。</p></li>
<li><p><strong>ユーザーの可用性</strong>: 呼び出されたユーザーが通信に応答できる状態にあるかを判断します。</p></li>
<li><p><strong>拡張性</strong>: 将来の機能追加や新しいサービスへの対応が容易なように、シンプルなコアプロトコルと拡張メカニズムを提供します。</p></li>
<li><p><strong>スケーラビリティ</strong>: 大規模なネットワークや多くのユーザーに対応できるよう設計されています。</p></li>
<li><p><strong>トランスポート非依存性</strong>: UDP、TCPなど、様々なトランスポートプロトコル上で動作できます。</p></li>
</ul>
<h2 class="wp-block-heading">詳細</h2>
<h3 class="wp-block-heading">プロトコルスタックにおける位置付け</h3>
<p>SIPはTCP/UDPの上で動作するアプリケーション層プロトコルです。OSI参照モデルではL7に位置し、実際のメディア転送を担うRTP/RTCPやセッション記述を行うSDPと連携します。</p>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
graph TD
A["アプリケーション"] --> B[SIP/SDP]
B --> C[RTP/RTCP]
C --> D[UDP/TCP]
D --> E[IP]
E --> F["データリンク層"]
F --> G["物理層"]
</pre></div>
<h3 class="wp-block-heading">SIPのアーキテクチャ</h3>
<p>SIPは主に以下のコンポーネントで構成されます[1]:</p>
<ul class="wp-block-list">
<li><p><strong>User Agent (UA)</strong>: SIP通信のエンドポイントであり、ユーザーの代わりにSIPセッションを開始、受信、および終了します。</p>
<ul>
<li><p><strong>User Agent Client (UAC)</strong>: SIPリクエストを開始するエンティティです。</p></li>
<li><p><strong>User Agent Server (UAS)</strong>: SIPリクエストを受信し、応答するエンティティです。</p></li>
</ul></li>
<li><p><strong>Proxy Server</strong>: UACから受信したリクエストを他のSIPサーバまたはUASに転送する中間サーバです。ルーティング、認証、アカウンティングなどの機能を提供できます。ステートフルまたはステートレスに動作します。</p></li>
<li><p><strong>Redirect Server</strong>: リクエストを処理するUASの連絡先URIをUACに返し、UACが直接UASにリクエストを送信するよう指示します。プロキシサーバとは異なり、リクエストを転送しません。</p></li>
<li><p><strong>Registrar Server</strong>: ユーザーの現在の場所（連絡先URI）をロケーションデータベースに登録するサーバです。REGISTERメソッドを処理します。</p></li>
</ul>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
graph TD
UAA["User Agent A (UAC)"] --> Proxy1["Proxy Server 1"]
Proxy1 --> Registrar["Registrar Server"]
Registrar --> DB["(Location Database)"]
Proxy1 --> Redirect["Redirect Server"]
Redirect --> UAB["User Agent B (UAS)"]
Proxy1 --> Proxy2["Proxy Server 2"]
Proxy2 --> UAB
</pre></div>
<h3 class="wp-block-heading">メッセージ構造</h3>
<p>SIPメッセージは、HTTPと同様にテキストベースで構成されます。メッセージは以下の要素からなります[1]:</p>
<ul class="wp-block-list">
<li><p><strong>開始行 (Start Line)</strong>:</p>
<ul>
<li><p>リクエストの場合: メソッド名、リクエストURI、SIPバージョン（例: <code>INVITE sip:bob@example.com SIP/2.0</code>）</p></li>
<li><p>レスポンスの場合: SIPバージョン、ステータスコード、理由フレーズ（例: <code>SIP/2.0 200 OK</code>）</p></li>
</ul></li>
<li><p><strong>ヘッダフィールド (Header Fields)</strong>: 各行が「ヘッダ名: 値」の形式で、メッセージのメタデータ（ルーティング情報、認証情報、セッション情報など）を含みます。</p></li>
<li><p><strong>空行</strong>: ヘッダフィールドの終わりを示します。</p></li>
<li><p><strong>メッセージボディ (Message Body)</strong>: 通常、SDPなどのセッション記述を含みます。</p></li>
</ul>
<p>以下は、典型的なSIP INVITEリクエストの構造例です。</p>
<div class="codehilite">
<pre data-enlighter-language="generic">INVITE sip:bob@example.com SIP/2.0 <-- 開始行 (メソッド、宛先URI、SIPバージョン)
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds <-- Viaヘッダ: メッセージが経由したパス
Max-Forwards: 70 <-- Max-Forwardsヘッダ: 最大転送ホップ数
To: Bob <sip:bob@example.com> <-- Toヘッダ: 呼び出し先の表示名とURI
From: Alice <sip:alice@example.com>;tag=1928301774 <-- Fromヘッダ: 呼び出し元の表示名とURI
Call-ID: a84b4c76e66710@pc33.example.com <-- Call-IDヘッダ: セッションを一意に識別
CSeq: 314159 INVITE <-- CSeqヘッダ: リクエストの順序を管理 (シーケンス番号とメソッド)
Contact: <sip:alice@pc33.example.com> <-- Contactヘッダ: 呼び出し元の現在の連絡先URI
Content-Type: application/sdp <-- Content-Typeヘッダ: メッセージボディのMIMEタイプ
Content-Length: 142 <-- Content-Lengthヘッダ: メッセージボディの長さ
v=0 <-- メッセージボディ (SDP)
o=alice 2890844526 2890844526 IN IP4 pc33.example.com
s=Session media
c=IN IP4 pc33.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
</pre>
</div>
<h3 class="wp-block-heading">主要メソッドとセッションフロー</h3>
<p>SIPは様々なメソッドを定義していますが、主要なものは以下の通りです[1]:</p>
<ul class="wp-block-list">
<li><p><strong>INVITE</strong>: セッション確立のためにユーザーを招待します。</p></li>
<li><p><strong>ACK</strong>: INVITEに対する最終的な応答（2xx成功応答など）を確認します。</p></li>
<li><p><strong>BYE</strong>: セッションを終了します。</p></li>
<li><p><strong>CANCEL</strong>: まだ確立されていないセッションに対する保留中のリクエストをキャンセルします。</p></li>
<li><p><strong>REGISTER</strong>: ユーザーの現在のロケーション情報をRegistrarに登録します。</p></li>
<li><p><strong>OPTIONS</strong>: サーバーまたはUAの能力を問い合わせます。</p></li>
</ul>
<p>以下は、典型的なSIPセッション確立から終了までのシーケンスです。</p>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
sequenceDiagram
participant UAC
participant Proxy
participant UAS
UAC ->> Proxy: INVITE sip:bob@example.com
Note over Proxy: ロケーションサービスでbobを探索
Proxy ->> UAS: INVITE sip:bob@example.com
UAS -->> Proxy: 100 Trying (試行中)
UAS -->> Proxy: 180 Ringing (呼び出し中)
Proxy -->> UAC: 180 Ringing
UAS -->> Proxy: 200 OK (SDP) (呼び出し応答、セッション記述含む)
Proxy -->> UAC: 200 OK (SDP)
UAC ->> UAS: ACK (200 OKの確認)
Note over UAC,UAS: これからメディアセッション (RTP/RTCP) が開始
UAC ->> UAS: BYE (セッション終了要求)
UAS -->> UAC: 200 OK (BYEの確認)
Note over UAC,UAS: メディアセッション終了
</pre></div>
<h3 class="wp-block-heading">トランザクションとダイアログ</h3>
<ul class="wp-block-list">
<li><p><strong>トランザクション</strong>: 1つのSIPリクエストとその最終的な応答、およびそれらの間に発生するすべての一時的な応答を含む、信頼性メカニズムの単位です。SIPは再送メカニズムやタイマーを用いてトランザクションの信頼性を確保します[1]。</p></li>
<li><p><strong>ダイアログ</strong>: 2つのUser Agent間のピアツーピアのSIPセッションを指します。Call-ID、Toタグ、Fromタグの組み合わせで一意に識別され、このダイアログ内の後続のメッセージ（BYEなど）は同じCall-IDとタグのペアを使用します。ダイアログはセッションの論理的な状態を維持します[1]。</p></li>
</ul>
<h2 class="wp-block-heading">相互運用性</h2>
<h3 class="wp-block-heading">他のプロトコルとの連携</h3>
<p>SIPは、それ単独でエンドツーエンドの通信を提供するわけではありません。リアルタイムマルチメディア通信を実現するためには、以下のプロトコルと緊密に連携します。</p>
<ul class="wp-block-list">
<li><p><strong>Session Description Protocol (SDP) (RFC 3264)</strong>: セッションのメディアタイプ、コーデック、ポート番号、IPアドレス、帯域幅などの詳細情報を記述するために、SIPメッセージのボディとしてSDPデータが埋め込まれます[4]。</p></li>
<li><p><strong>Real-time Transport Protocol (RTP) および RTCP (RFC 3550)</strong>: SIPによって確立されたセッション上で、実際の音声やビデオなどのリアルタイムメディアデータを転送するために使用されます。RTCPはRTPセッションの品質監視と制御を提供します。</p></li>
</ul>
<h3 class="wp-block-heading">HTTPとの比較</h3>
<figure class="wp-block-table"><table>
<thead>
<tr>
<th style="text-align:left;">特徴</th>
<th style="text-align:left;">SIP (RFC 3261)</th>
<th style="text-align:left;">HTTP/1.1 (RFC 9110, RFC 9112)</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left;"><strong>目的</strong></td>
<td style="text-align:left;">リアルタイムマルチメディアセッションの制御</td>
<td style="text-align:left;">Webコンテンツの取得、汎用的なデータ転送</td>
</tr>
<tr>
<td style="text-align:left;"><strong>メッセージ</strong></td>
<td style="text-align:left;">リクエスト/レスポンス (テキストベース)</td>
<td style="text-align:left;">リクエスト/レスポンス (テキストベース)</td>
</tr>
<tr>
<td style="text-align:left;"><strong>メソッド</strong></td>
<td style="text-align:left;">INVITE, ACK, BYE, REGISTERなど</td>
<td style="text-align:left;">GET, POST, PUT, DELETEなど</td>
</tr>
<tr>
<td style="text-align:left;"><strong>ステート</strong></td>
<td style="text-align:left;">トランザクションはステートフル、プロキシはステートフル/レスレス両方可。ダイアログはステートフル</td>
<td style="text-align:left;">基本的にステートレス、セッション管理はCookieなど</td>
</tr>
<tr>
<td style="text-align:left;"><strong>URIスキーム</strong></td>
<td style="text-align:left;"><code>sip:</code> または <code>sips:</code></td>
<td style="text-align:left;"><code>http:</code> または <code>https:</code></td>
</tr>
<tr>
<td style="text-align:left;"><strong>トランスポート</strong></td>
<td style="text-align:left;">UDP/TCP (通常5060番ポート)</td>
<td style="text-align:left;">TCP (通常80/443番ポート)</td>
</tr>
<tr>
<td style="text-align:left;"><strong>永続性</strong></td>
<td style="text-align:left;">接続ごとに複数のメッセージ交換（ダイアログ）</td>
<td style="text-align:left;">接続ごとに複数リクエスト（HTTP/1.1 Keep-Alive）</td>
</tr>
</tbody>
</table></figure>
<h2 class="wp-block-heading">セキュリティ考慮事項</h2>
<p>SIPは、悪意のある攻撃に対して脆弱であるため、RFC 3261のセクション23に詳細なセキュリティ考慮事項が記載されています[1]。</p>
<ul class="wp-block-list">
<li><p><strong>盗聴 (Eavesdropping)</strong>: ネットワーク上で交換されるSIPメッセージやSDP情報を傍受されるリスクがあります。</p>
<ul>
<li><strong>対策</strong>: <code>sips:</code> URIの使用、TLS (Transport Layer Security) または DTLS (Datagram Transport Layer Security) を使用してシグナリングパスを暗号化します。メディアについてもSRTP (Secure Real-time Transport Protocol) を用いて暗号化します。</li>
</ul></li>
<li><p><strong>改ざん (Tampering)</strong>: メッセージが転送中に変更され、不正な情報が注入される可能性があります。</p>
<ul>
<li><strong>対策</strong>: TLS/DTLSによる完全性保護、S/MIME (Secure/Multipurpose Internet Mail Extensions) を用いたメッセージボディの署名・暗号化。</li>
</ul></li>
<li><p><strong>なりすまし (Impersonation)</strong>: 攻撃者が正当なユーザーやサーバになりすまして通信を行う可能性があります。</p>
<ul>
<li><strong>対策</strong>: ダイジェスト認証 (RFC 2617) やクライアント証明書を用いたTLSによる相互認証。</li>
</ul></li>
<li><p><strong>サービス拒否 (DoS) 攻撃</strong>: 大量の不正なメッセージを送信することで、SIPサーバやUAをオーバーロードさせ、サービスを停止させる可能性があります。</p>
<ul>
<li><strong>対策</strong>: 適切なアクセス制御、レート制限、不正トラフィックのフィルタリング。</li>
</ul></li>
<li><p><strong>リプレイ攻撃 (Replay Attacks)</strong>: 以前にキャプチャされた有効なメッセージを再送信することで、不正な動作を引き起こす可能性があります。</p>
<ul>
<li><strong>対策</strong>: CSeqヘッダやNonce値を用いたダイジェスト認証。SIPメッセージにタイムスタンプを含めることも有効です。</li>
</ul></li>
<li><p><strong>ダウングレード攻撃 (Downgrade Attacks)</strong>: より強力なセキュリティメカニズムが利用可能な場合でも、攻撃者が通信をより脆弱なメカニズムにダウングレードさせようとする可能性があります。</p>
<ul>
<li><strong>対策</strong>: SIPS URIの使用を強制し、安全なトランスポート（TLS）以外の利用を拒否する設定。</li>
</ul></li>
</ul>
<h2 class="wp-block-heading">実装メモ</h2>
<p>SIPの実装には、ネットワーク環境やアプリケーションの要件に応じて以下の点を考慮する必要があります。</p>
<ul class="wp-block-list">
<li><p><strong>MTU (Maximum Transmission Unit) / Path MTU</strong>: UDPを使用する場合、MTUを超えるサイズのSIPメッセージはIPフラグメンテーションを引き起こす可能性があります。これはパケットロスやパフォーマンス低下の原因となるため、メッセージサイズを小さく保つか、TCPを使用することを検討します。Path MTU Discovery (PMTUD) を利用して適切なメッセージサイズを決定することも重要です。</p></li>
<li><p><strong>HOL blocking回避 (Head-of-Line Blocking)</strong>: TCPを使用する場合、1つのストリームでパケットロスが発生すると、その後のパケットがすべて停止するHOL blockingが発生する可能性があります。SIPプロキシが多数のセッションを処理する場合、HOL blockingはパフォーマンスに影響を与えます。複数のTCP接続を利用するか、UDPベースのSCTP (Stream Control Transmission Protocol) のようなマルチストリームプロトコルを検討することが回避策となります。</p></li>
<li><p><strong>キュー制御と優先度 (QoS)</strong>: リアルタイム通信であるSIP/RTPは、パケット遅延やジッターに敏感です。ネットワーク機器やOSレベルでのQoS（DiffServ, IntServなど）を設定し、SIPシグナリングやRTPメディアパケットに高い優先度を与えることで、通信品質を確保します。</p></li>
<li><p><strong>NAT/ファイアウォール越え</strong>: SIPはIPアドレスとポート番号をメッセージボディ（SDP）に含めるため、NATやファイアウォールを越える際に問題が発生しやすいです。</p>
<ul>
<li><strong>対策</strong>: STUN (Session Traversal Utilities for NAT)、TURN (Traversal Using Relays around NAT)、ICE (Interactive Connectivity Establishment) (RFC 8445) などのプロトコルを用いて、NAT越えを可能にします[6]。SIPメッセージのViaヘッダに<code>rport</code>パラメータを追加することも、NATの背後にあるUACへの応答ルーティングを助けます (RFC 3581)[5]。</li>
</ul></li>
<li><p><strong>タイマー管理</strong>: SIPトランザクションは、様々なタイマー (T1, T2, T4など) に基づいて再送やタイムアウトを処理します[1]。これらのタイマーの適切な設定と正確な管理は、プロトコルの信頼性と効率性を確保するために不可欠です。</p></li>
</ul>
<h2 class="wp-block-heading">まとめ</h2>
<p>SIP (Session Initiation Protocol) は、RFC 3261によって定義された、リアルタイムマルチメディアセッションの確立、管理、終了のための基盤プロトコルです。HTTPに似たテキストベースのメッセージングと柔軟なアーキテクチャを持ち、UAC、UAS、Proxy、Registrarなどのコンポーネントが連携して動作します。SDPやRTPといった他のプロトコルと組み合わせることで、VoIPやビデオ会議などの多様な通信サービスを実現します。</p>
<p>実装においては、セキュリティ（盗聴、改ざん、なりすまし、DoS攻撃への対策としてのTLS/SRTP、認証）とネットワーク特性（MTU、NAT越え、QoS）を深く考慮することが不可欠です。これらの側面を適切に設計・実装することで、堅牢で信頼性の高いリアルタイム通信システムを構築できます。</p>
<h2 class="wp-block-heading">参考文献</h2>
<ol class="wp-block-list">
<li><p>J. Rosenberg et al., “SIP: Session Initiation Protocol”, IETF RFC 3261, June 2002. <a href="https://datatracker.ietf.org/doc/html/rfc3261">https://datatracker.ietf.org/doc/html/rfc3261</a> (最終アクセス: 2024年7月26日)</p></li>
<li><p>A. B. Roach, “Session Initiation Protocol (SIP) Specific Event Notification”, IETF RFC 3265, June 2002. <a href="https://datatracker.ietf.org/doc/html/rfc3265">https://datatracker.ietf.org/doc/html/rfc3265</a> (最終アクセス: 2024年7月26日)</p></li>
<li><p>J. Rosenberg, “The Session Initiation Protocol (SIP) UPDATE Method”, IETF RFC 3311, September 2002. <a href="https://datatracker.ietf.org/doc/html/rfc3311">https://datatracker.ietf.org/doc/html/rfc3311</a> (最終アクセス: 2024年7月26日)</p></li>
<li><p>J. Rosenberg, H. Schulzrinne, “An Offer/Answer Model with the Session Description Protocol (SDP)”, IETF RFC 3264, June 2002. <a href="https://datatracker.ietf.org/doc/html/rfc3264">https://datatracker.ietf.org/doc/html/rfc3264</a> (最終アクセス: 2024年7月26日)</p></li>
<li><p>J. Rosenberg, J. Peterson, “An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing”, IETF RFC 3581, August 2003. <a href="https://datatracker.ietf.org/doc/html/rfc3581">https://datatracker.ietf.org/doc/html/rfc3581</a> (最終アクセス: 2024年7月26日)</p></li>
<li><p>T. Vijayan et al., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols”, IETF RFC 8445, September 2018. <a href="https://datatracker.ietf.org/doc/html/rfc8445">https://datatracker.ietf.org/doc/html/rfc8445</a> (最終アクセス: 2024年7月26日)</p></li>
</ol>
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証） です。
SIP (Session Initiation Protocol)の基本解説 – RFC 3261準拠
背景 Session Initiation Protocol (SIP) は、VoIP（Voice over IP）やマルチメディア通信において、セッションの確立、変更、終了を制御するためのアプリケーション層のシグナリングプロトコルです。インターネット上でのリアルタイム通信の基盤として広く採用されており、HTTPに類似したテキストベースのメッセージングとクライアント-サーバモデルを特徴とします。
SIPは、IETFによって標準化されており、その主要な仕様は2002年6月に発行されたRFC 3261「SIP: Session Initiation Protocol」に定義されています[1]。このプロトコルは、メディアセッション自体を転送するのではなく、参加者のアドレス解決、能力ネゴシエーション、セッション確立、セッション管理（一時停止、転送、終了など）といった「シグナリング」を担当します。実際のメディアデータ（音声やビデオなど）の転送には、通常、Real-time Transport Protocol (RTP) が用いられ、セッションの内容（コーデック、ポート番号など）はSession Description Protocol (SDP) で記述されます[4]。
設計目標 RFC 3261に記載されているSIPの主な設計目標は以下の通りです[1]:
参加者の特定と位置特定 : ユーザーを特定し、その現在のネットワークアドレスを解決するメカニズムを提供します。
参加者の能力ネゴシエーション : 通信セッションで利用可能なメディアタイプ、コーデック、その他のパラメータを交換し、合意するための手段を提供します。
セッションの確立と管理 : セッションの開始、中断、再開、変更、終了といったライフサイクル全体を管理します。
ユーザーの可用性 : 呼び出されたユーザーが通信に応答できる状態にあるかを判断します。
拡張性 : 将来の機能追加や新しいサービスへの対応が容易なように、シンプルなコアプロトコルと拡張メカニズムを提供します。
スケーラビリティ : 大規模なネットワークや多くのユーザーに対応できるよう設計されています。
トランスポート非依存性 : UDP、TCPなど、様々なトランスポートプロトコル上で動作できます。
詳細 プロトコルスタックにおける位置付け SIPはTCP/UDPの上で動作するアプリケーション層プロトコルです。OSI参照モデルではL7に位置し、実際のメディア転送を担うRTP/RTCPやセッション記述を行うSDPと連携します。
graph TD
A["アプリケーション"] --> B[SIP/SDP]
B --> C[RTP/RTCP]
C --> D[UDP/TCP]
D --> E[IP]
E --> F["データリンク層"]
F --> G["物理層"]
SIPのアーキテクチャ SIPは主に以下のコンポーネントで構成されます[1]:
User Agent (UA) : SIP通信のエンドポイントであり、ユーザーの代わりにSIPセッションを開始、受信、および終了します。
Proxy Server : UACから受信したリクエストを他のSIPサーバまたはUASに転送する中間サーバです。ルーティング、認証、アカウンティングなどの機能を提供できます。ステートフルまたはステートレスに動作します。
Redirect Server : リクエストを処理するUASの連絡先URIをUACに返し、UACが直接UASにリクエストを送信するよう指示します。プロキシサーバとは異なり、リクエストを転送しません。
Registrar Server : ユーザーの現在の場所（連絡先URI）をロケーションデータベースに登録するサーバです。REGISTERメソッドを処理します。
graph TD
UAA["User Agent A (UAC)"] --> Proxy1["Proxy Server 1"]
Proxy1 --> Registrar["Registrar Server"]
Registrar --> DB["(Location Database)"]
Proxy1 --> Redirect["Redirect Server"]
Redirect --> UAB["User Agent B (UAS)"]
Proxy1 --> Proxy2["Proxy Server 2"]
Proxy2 --> UAB
メッセージ構造 SIPメッセージは、HTTPと同様にテキストベースで構成されます。メッセージは以下の要素からなります[1]:
以下は、典型的なSIP INVITEリクエストの構造例です。
INVITE sip:bob@example.com SIP/2.0 <-- 開始行 (メソッド、宛先URI、SIPバージョン)
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds <-- Viaヘッダ: メッセージが経由したパス
Max-Forwards: 70 <-- Max-Forwardsヘッダ: 最大転送ホップ数
To: Bob <sip:bob@example.com> <-- Toヘッダ: 呼び出し先の表示名とURI
From: Alice <sip:alice@example.com>;tag=1928301774 <-- Fromヘッダ: 呼び出し元の表示名とURI
Call-ID: a84b4c76e66710@pc33.example.com <-- Call-IDヘッダ: セッションを一意に識別
CSeq: 314159 INVITE <-- CSeqヘッダ: リクエストの順序を管理 (シーケンス番号とメソッド)
Contact: <sip:alice@pc33.example.com> <-- Contactヘッダ: 呼び出し元の現在の連絡先URI
Content-Type: application/sdp <-- Content-Typeヘッダ: メッセージボディのMIMEタイプ
Content-Length: 142 <-- Content-Lengthヘッダ: メッセージボディの長さ
v=0 <-- メッセージボディ (SDP)
o=alice 2890844526 2890844526 IN IP4 pc33.example.com
s=Session media
c=IN IP4 pc33.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
主要メソッドとセッションフロー SIPは様々なメソッドを定義していますが、主要なものは以下の通りです[1]:
INVITE : セッション確立のためにユーザーを招待します。
ACK : INVITEに対する最終的な応答（2xx成功応答など）を確認します。
BYE : セッションを終了します。
CANCEL : まだ確立されていないセッションに対する保留中のリクエストをキャンセルします。
REGISTER : ユーザーの現在のロケーション情報をRegistrarに登録します。
OPTIONS : サーバーまたはUAの能力を問い合わせます。
以下は、典型的なSIPセッション確立から終了までのシーケンスです。
sequenceDiagram
participant UAC
participant Proxy
participant UAS
UAC ->> Proxy: INVITE sip:bob@example.com
Note over Proxy: ロケーションサービスでbobを探索
Proxy ->> UAS: INVITE sip:bob@example.com
UAS -->> Proxy: 100 Trying (試行中)
UAS -->> Proxy: 180 Ringing (呼び出し中)
Proxy -->> UAC: 180 Ringing
UAS -->> Proxy: 200 OK (SDP) (呼び出し応答、セッション記述含む)
Proxy -->> UAC: 200 OK (SDP)
UAC ->> UAS: ACK (200 OKの確認)
Note over UAC,UAS: これからメディアセッション (RTP/RTCP) が開始
UAC ->> UAS: BYE (セッション終了要求)
UAS -->> UAC: 200 OK (BYEの確認)
Note over UAC,UAS: メディアセッション終了
トランザクションとダイアログ
トランザクション : 1つのSIPリクエストとその最終的な応答、およびそれらの間に発生するすべての一時的な応答を含む、信頼性メカニズムの単位です。SIPは再送メカニズムやタイマーを用いてトランザクションの信頼性を確保します[1]。
ダイアログ : 2つのUser Agent間のピアツーピアのSIPセッションを指します。Call-ID、Toタグ、Fromタグの組み合わせで一意に識別され、このダイアログ内の後続のメッセージ（BYEなど）は同じCall-IDとタグのペアを使用します。ダイアログはセッションの論理的な状態を維持します[1]。
相互運用性 他のプロトコルとの連携 SIPは、それ単独でエンドツーエンドの通信を提供するわけではありません。リアルタイムマルチメディア通信を実現するためには、以下のプロトコルと緊密に連携します。
Session Description Protocol (SDP) (RFC 3264) : セッションのメディアタイプ、コーデック、ポート番号、IPアドレス、帯域幅などの詳細情報を記述するために、SIPメッセージのボディとしてSDPデータが埋め込まれます[4]。
Real-time Transport Protocol (RTP) および RTCP (RFC 3550) : SIPによって確立されたセッション上で、実際の音声やビデオなどのリアルタイムメディアデータを転送するために使用されます。RTCPはRTPセッションの品質監視と制御を提供します。
HTTPとの比較
特徴
SIP (RFC 3261)
HTTP/1.1 (RFC 9110, RFC 9112)
目的 リアルタイムマルチメディアセッションの制御
Webコンテンツの取得、汎用的なデータ転送
メッセージ リクエスト/レスポンス (テキストベース)
リクエスト/レスポンス (テキストベース)
メソッド INVITE, ACK, BYE, REGISTERなど
GET, POST, PUT, DELETEなど
ステート トランザクションはステートフル、プロキシはステートフル/レスレス両方可。ダイアログはステートフル
基本的にステートレス、セッション管理はCookieなど
URIスキーム sip: または sips:http: または https:
トランスポート UDP/TCP (通常5060番ポート)
TCP (通常80/443番ポート)
永続性 接続ごとに複数のメッセージ交換（ダイアログ）
接続ごとに複数リクエスト（HTTP/1.1 Keep-Alive）
セキュリティ考慮事項 SIPは、悪意のある攻撃に対して脆弱であるため、RFC 3261のセクション23に詳細なセキュリティ考慮事項が記載されています[1]。
盗聴 (Eavesdropping) : ネットワーク上で交換されるSIPメッセージやSDP情報を傍受されるリスクがあります。
対策 : sips: URIの使用、TLS (Transport Layer Security) または DTLS (Datagram Transport Layer Security) を使用してシグナリングパスを暗号化します。メディアについてもSRTP (Secure Real-time Transport Protocol) を用いて暗号化します。 改ざん (Tampering) : メッセージが転送中に変更され、不正な情報が注入される可能性があります。
対策 : TLS/DTLSによる完全性保護、S/MIME (Secure/Multipurpose Internet Mail Extensions) を用いたメッセージボディの署名・暗号化。 なりすまし (Impersonation) : 攻撃者が正当なユーザーやサーバになりすまして通信を行う可能性があります。
対策 : ダイジェスト認証 (RFC 2617) やクライアント証明書を用いたTLSによる相互認証。 サービス拒否 (DoS) 攻撃 : 大量の不正なメッセージを送信することで、SIPサーバやUAをオーバーロードさせ、サービスを停止させる可能性があります。
対策 : 適切なアクセス制御、レート制限、不正トラフィックのフィルタリング。 リプレイ攻撃 (Replay Attacks) : 以前にキャプチャされた有効なメッセージを再送信することで、不正な動作を引き起こす可能性があります。
対策 : CSeqヘッダやNonce値を用いたダイジェスト認証。SIPメッセージにタイムスタンプを含めることも有効です。 ダウングレード攻撃 (Downgrade Attacks) : より強力なセキュリティメカニズムが利用可能な場合でも、攻撃者が通信をより脆弱なメカニズムにダウングレードさせようとする可能性があります。
対策 : SIPS URIの使用を強制し、安全なトランスポート（TLS）以外の利用を拒否する設定。
実装メモ SIPの実装には、ネットワーク環境やアプリケーションの要件に応じて以下の点を考慮する必要があります。
MTU (Maximum Transmission Unit) / Path MTU : UDPを使用する場合、MTUを超えるサイズのSIPメッセージはIPフラグメンテーションを引き起こす可能性があります。これはパケットロスやパフォーマンス低下の原因となるため、メッセージサイズを小さく保つか、TCPを使用することを検討します。Path MTU Discovery (PMTUD) を利用して適切なメッセージサイズを決定することも重要です。
HOL blocking回避 (Head-of-Line Blocking) : TCPを使用する場合、1つのストリームでパケットロスが発生すると、その後のパケットがすべて停止するHOL blockingが発生する可能性があります。SIPプロキシが多数のセッションを処理する場合、HOL blockingはパフォーマンスに影響を与えます。複数のTCP接続を利用するか、UDPベースのSCTP (Stream Control Transmission Protocol) のようなマルチストリームプロトコルを検討することが回避策となります。
キュー制御と優先度 (QoS) : リアルタイム通信であるSIP/RTPは、パケット遅延やジッターに敏感です。ネットワーク機器やOSレベルでのQoS（DiffServ, IntServなど）を設定し、SIPシグナリングやRTPメディアパケットに高い優先度を与えることで、通信品質を確保します。
NAT/ファイアウォール越え : SIPはIPアドレスとポート番号をメッセージボディ（SDP）に含めるため、NATやファイアウォールを越える際に問題が発生しやすいです。
対策 : STUN (Session Traversal Utilities for NAT)、TURN (Traversal Using Relays around NAT)、ICE (Interactive Connectivity Establishment) (RFC 8445) などのプロトコルを用いて、NAT越えを可能にします[6]。SIPメッセージのViaヘッダにrportパラメータを追加することも、NATの背後にあるUACへの応答ルーティングを助けます (RFC 3581)[5]。 タイマー管理 : SIPトランザクションは、様々なタイマー (T1, T2, T4など) に基づいて再送やタイムアウトを処理します[1]。これらのタイマーの適切な設定と正確な管理は、プロトコルの信頼性と効率性を確保するために不可欠です。
まとめ SIP (Session Initiation Protocol) は、RFC 3261によって定義された、リアルタイムマルチメディアセッションの確立、管理、終了のための基盤プロトコルです。HTTPに似たテキストベースのメッセージングと柔軟なアーキテクチャを持ち、UAC、UAS、Proxy、Registrarなどのコンポーネントが連携して動作します。SDPやRTPといった他のプロトコルと組み合わせることで、VoIPやビデオ会議などの多様な通信サービスを実現します。
実装においては、セキュリティ（盗聴、改ざん、なりすまし、DoS攻撃への対策としてのTLS/SRTP、認証）とネットワーク特性（MTU、NAT越え、QoS）を深く考慮することが不可欠です。これらの側面を適切に設計・実装することで、堅牢で信頼性の高いリアルタイム通信システムを構築できます。
参考文献
J. Rosenberg et al., “SIP: Session Initiation Protocol”, IETF RFC 3261, June 2002. https://datatracker.ietf.org/doc/html/rfc3261 (最終アクセス: 2024年7月26日)
A. B. Roach, “Session Initiation Protocol (SIP) Specific Event Notification”, IETF RFC 3265, June 2002. https://datatracker.ietf.org/doc/html/rfc3265 (最終アクセス: 2024年7月26日)
J. Rosenberg, “The Session Initiation Protocol (SIP) UPDATE Method”, IETF RFC 3311, September 2002. https://datatracker.ietf.org/doc/html/rfc3311 (最終アクセス: 2024年7月26日)
J. Rosenberg, H. Schulzrinne, “An Offer/Answer Model with the Session Description Protocol (SDP)”, IETF RFC 3264, June 2002. https://datatracker.ietf.org/doc/html/rfc3264 (最終アクセス: 2024年7月26日)
J. Rosenberg, J. Peterson, “An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing”, IETF RFC 3581, August 2003. https://datatracker.ietf.org/doc/html/rfc3581 (最終アクセス: 2024年7月26日)
T. Vijayan et al., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols”, IETF RFC 8445, September 2018. https://datatracker.ietf.org/doc/html/rfc8445 (最終アクセス: 2024年7月26日)
コメント