本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
SIP INVITEとSDP Offer/Answerモデル（RFC 3261準拠）
背景
Session Initiation Protocol（SIP）は、IPネットワーク上でマルチメディアセッション（音声通話、ビデオ会議など）を開始、変更、終了するためのシグナリングプロトコルです。その中核をなすのが「INVITE」メソッドであり、これによってセッション確立の要求が開始されます。セッションの詳細（どのメディアを使うか、どのコーデックを使うか、どのIPアドレスとポートを使うかなど）は、Session Description Protocol（SDP）を用いて記述され、「Offer/Answerモデル」という枠組みでネゴシエーションされます。これらの仕様は主にRFC 3261で定義され、SDP Offer/Answerモデル自体はRFC 3264で詳細が規定されています。
設計目標
SIP INVITEとSDP Offer/Answerモデルは、以下の主要な設計目標を達成するために考案されました。
柔軟なセッション確立: 異なるエンドポイント間で多様なメディア種別（音声、ビデオ、データなど）やコーデックを柔軟にネゴシエートし、セッションを確立する。
メディア特性の動的記述: リアルタイムな通信セッションに必要なメディアの種類、トランスポートアドレス、ポート番号、コーデック、帯域幅などの詳細を記述する。
中間要素による拡張性: プロキシサーバやリダイレクトサーバといった中間要素がセッション確立プロセスに関与し、ルーティング、負荷分散、セキュリティなどの機能を提供できるようにする。
信頼性と状態管理: シグナリングメッセージの信頼性のある配送と、セッションの状態（ダイアログ）管理を可能にする。
既存プロトコルとの連携: RTP/RTCPといったメディアトランスポートプロトコルや、NAT/ファイアウォールトラバーサル機構と連携できるように設計する。
詳細
SIP INVITEメッセージ構造
SIP INVITEメッセージは、セッションの開始を要求するもので、URI形式のアドレス指定、多数のヘッダフィールド、そしてオプションでメッセージボディ（通常はSDP）を含みます。
INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bK776asdhds Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=1928301774 To: Bob <sip:bob@biloxi.example.com> Call-ID: a84b4c76e66710@pc33.atlanta.example.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142 (SDP Offer goes here)
主要なヘッダフィールドとその役割は以下の通りです。
Request-Line:
Method:INVITE(セッション開始要求)Request-URI:sip:bob@biloxi.example.com(宛先URI)SIP-Version:SIP/2.0(SIPプロトコルバージョン)
Via:
pc33.atlanta.example.com;branch=z9hG4bK776asdhds(メッセージが経由したパスを記録し、応答のルーティングに使用。branchパラメータはトランザクション識別子)Max-Forwards:
70(メッセージが転送される最大ホップ数)From:
Alice <sip:alice@atlanta.example.com>;tag=1928301774(発信者の情報。tagはダイアログ識別子)To:
Bob <sip:bob@biloxi.example.com>(着信者の情報。tagは応答で追加され、ダイアログ識別子となる)Call-ID:
a84b4c76e66710@pc33.atlanta.example.com(セッション全体を識別するユニークなID)CSeq:
314159 INVITE(要求の順序を管理するシーケンス番号とメソッド名)Contact:
<sip:alice@pc33.atlanta.example.com>(発信者の直接的な連絡先アドレス。応答のルーティングに使用)Content-Type:
application/sdp(メッセージボディのタイプを指定)Content-Length:
142(メッセージボディの長さ)
SDP Offer/Answerモデル
SDP Offer/Answerモデル（RFC 3264）は、二つのエンドポイント間でセッションの特性をネゴシエートするためのメカニズムです。
Offer: セッションの開始側（または変更要求側）が、利用可能なメディアタイプ、コーデック、トランスポート情報、その他のセッションパラメータを提示するSDP記述。
Answer: Offerを受け取った側が、Offerの内容を検証し、自身の能力に基づいて受け入れる、拒否する、または修正したセッションパラメータを返すSDP記述。
通常、SIP INVITEメソッドのメッセージボディにSDP Offerが含まれ、それに対する200 OK応答のメッセージボディにSDP Answerが含まれます。
v=0 o=alice 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=SIP Call c=IN IP4 192.0.2.1 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000
上記のSDP例では、以下の情報が示されています。
v=0: SDPバージョン。o=: OriginatorとセッションID。s=: セッション名。c=: 接続情報（IPアドレス）。t=: タイムスタンプ。m=: メディア記述（ここでは音声とビデオ）。audio 49170 RTP/AVP 0: 音声メディア、ポート49170、RTP/AVPプロファイル、ペイロードタイプ0 (PCMU)。video 51372 RTP/AVP 31: ビデオメディア、ポート51372、RTP/AVPプロファイル、ペイロードタイプ31 (H261)。
a=: 属性（ここではRTPマッピング）。
セッション中にメディアを追加したり、コーデックを変更したりする場合は、再度INVITE（re-INVITE）またはUPDATE（RFC 3311）メソッドを使って新しいOffer/Answerの交換が行われます。
セッション確立シーケンス
SIP INVITEとSDP Offer/Answerモデルによる基本的なセッション確立フローは以下のようになります。
sequenceDiagram
participant "UAC as 発信者 (UAC)"
participant Proxy as SIPプロキシ
participant "UAS as 着信者 (UAS)"
UAC ->> Proxy: INVITE (SDP Offer: Audio/Video codecs, IP, Port)
Note over UAC,Proxy: セッション開始要求とメディア提案
Proxy ->> UAS: INVITE (SDP Offer: Audio/Video codecs, IP, Port)
UAS ->> Proxy: 100 Trying
Note over UAS,Proxy: 処理中
UAS ->> Proxy: 180 Ringing
Note over UAS,Proxy: 着信者に通知、呼び出し中
UAS ->> Proxy: 200 OK (SDP Answer: Accepted codecs, IP, Port)
Note over UAS,Proxy: 呼び出しに応答、メディア合意
Proxy ->> UAC: 200 OK (SDP Answer: Accepted codecs, IP, Port)
UAC ->> Proxy: ACK
Note over UAC,Proxy: 200 OKに対する確認
Proxy ->> UAS: ACK
Note over Proxy,UAS: 確認応答
Note over UAC,UAS: メディアセッション開始 (RTP/RTCP)
このシーケンスでは、発信者(UAC)がINVITEメッセージでSDP Offerを送信し、着信者(UAS)が200 OKメッセージでSDP Answerを返します。UACからのACKでセッション確立が完了し、その後RTP/RTCPを用いたメディア通信が開始されます。
相互運用
SIP INVITEとSDP Offer/Answerモデルは、VoIPやリアルタイム通信エコシステムにおいて、様々なプロトコルやシステムとの相互運用を前提として設計されています。
SIPとSDPの緊密な連携: SIPはシグナリングを担当し、SDPはメディア記述を担当することで、役割分担が明確化され、柔軟なセッション管理を実現しています。
メディアプロトコルとの連携: SIP/SDPでネゴシエートされたパラメータ（IPアドレス、ポート、コーデックなど）に基づき、Real-time Transport Protocol (RTP) および RTP Control Protocol (RTCP) を用いて実際のメディアストリームが送受信されます。
ゲートウェイとの連携: SIPゲートウェイを介して、PSTN（公衆交換電話網）などのレガシーな電話システムとの接続を可能にします。SDPはPSTNとのメディア変換情報も記述できます。
NAT/ファイアウォールトラバーサル: STUN/TURN/ICEなどのプロトコルと連携し、NATやファイアウォールを越えたセッション確立を支援します。SDPにはこれらの情報を記述する属性（例:
a=candidate)を含めることができます。既存プロトコルとの比較:
HTTPとの比較: SIPはHTTPと同様にテキストベースのメッセージングとリクエスト/レスポンスモデルを使用しますが、HTTPが主にステートレスなデータ転送プロトコルであるのに対し、SIPはトランザクション（RFC 3261 Section 17）とダイアログ（RFC 3261 Section 12）という概念により、状態管理されたセッション確立と制御に特化しています。また、SIPは多種多様なプロキシタイプ（状態保持プロキシ、ステートレスプロキシ、フォークプロキシなど）をサポートし、複雑なルーティングとサービスを提供できます。
HTTP/2, HTTP/3との比較: SIPはHTTP/1.1に基づいているため、HTTP/2やHTTP/3が提供するような多重化、バイナリフレーミング、QUICベースのトランスポート最適化といった高度なメカニズムは持ちません。SIPメッセージは通常、TCPまたはUDP上で個別に送受信されます。このため、HOL blocking回避などの実装上の課題は、SIP自体よりも基盤となるトランスポート層（TCP）に依存します。
セキュリティ考慮
SIP INVITEとSDP Offer/Answerモデルを実装・運用する際には、以下のセキュリティ考慮事項が重要です。
盗聴と改ざん: SIPメッセージやSDPの内容がネットワーク上で傍受され、機密情報が漏洩したり、セッションパラメータが改ざんされたりするリスクがあります。
- 対策: SIP over TLS (SIPS URI) を用いてシグナリングメッセージを暗号化し、機密性と完全性を確保します。メディアストリームにはSecure Real-time Transport Protocol (SRTP) を使用します。
なりすまし: 悪意のある第三者が正規のユーザになりすましてINVITEメッセージを送信し、不正なセッションを確立したり、サービス妨害を行ったりする可能性があります。
- 対策: SIP認証（Digest認証など）を用いてユーザの身元を確認します。証明書ベースの認証（TLS Client Certificates）も有効です。
サービス妨害（DoS）攻撃: 大量のINVITEメッセージを送信してサーバのリソースを枯渇させたり、電話を鳴らし続ける「電話攻撃」（telephony denial of service）を引き起こしたりする可能性があります。
- 対策: レートリミット、ブラックリスト、IPアドレスベースのフィルタリング、SIPファイアウォール、B2BUA（Back-to-Back User Agent）によるセッション状態管理などが有効です。
リプレイ攻撃: 過去に傍受されたSIPメッセージが再送され、不正なアクションが実行される可能性があります。
- 対策: CSeqヘッダのシーケンス番号や、Digest認証のnonce値とクライアントnonce (cnonce) を用いて、メッセージの新鮮さ（freshness）を確保します。
ダウングレード攻撃: 攻撃者がSDP Offer/Answerのネゴシエーション中に、意図的にセキュリティレベルの低いコーデックやメディアタイプを選択させたり、暗号化を無効にさせたりする可能性があります。
- 対策: SDPで提示されるオプションに優先順位をつけ、セキュアなオプションを優先します。ポリシーにより特定の非セキュアなオプションを拒否するように設定します。
キー更新: メディア暗号化にSRTPを使用する場合、暗号鍵の定期的な更新が推奨されます。SIPシグナリングは、鍵交換プロトコル（例: MIKEY, DTLS-SRTP）のシグナリングチャネルとして利用できます。
0-RTT（Zero Round-Trip Time）の再送リスク: SIPのINVITEプロセス自体は完全な0-RTTではありませんが、初期のOfferでSDPがすぐに提示されるため、もし暗号化されていない状態で送信され、そのOfferが再利用された場合、情報漏洩やセッションハイジャックのリスクが生じる可能性があります。SIPトランザクションにおける再送メカニズムは、トランザクション状態の維持と重複メッセージの検出によって保護されていますが、初期のOfferのセキュリティはTLS等の上位層で確保されるべきです。
実装メモ
SIP INVITEとSDP Offer/Answerモデルの実装には、以下の点に注意が必要です。
MTU (Maximum Transmission Unit) / Path MTU:
UDPでSIPメッセージを送信する場合、メッセージサイズがMTU（通常1500バイト）を超えるとIPフラグメンテーションが発生し、パケットロスやパフォーマンス低下のリスクが高まります。特にSDPボディが複雑で長くなる場合、この問題が発生しやすくなります。
対策: Path MTU Discovery (PMTUD) のサポートや、SIPメッセージのサイズをUDP MTU内に収める工夫（SDPの簡素化など）が必要です。または、信頼性が必要な場合はTCPトランスポートを使用することを検討します。
HOL (Head-of-Line) Blocking回避:
TCPは信頼性のある順序保証されたデータ転送を提供しますが、セグメントのロスが発生した場合、その後の全てのセグメントが受信バッファに到着していても、ロスしたセグメントの再送が完了するまでアプリケーション層にデータが渡されません（HOL blocking）。これはリアルタイム通信の遅延に悪影響を及ぼす可能性があります。
対策: SIPはUDPもサポートしており、UDPはHOL blockingの影響を受けません。しかしUDPは信頼性がないため、SIPアプリケーション層で再送やタイマー管理（INVITEトランザクションタイマーT1, T2, T4など）を適切に実装する必要があります。複数のTCP接続を使用することもHOL blocking回避策の一つです。
キュー制御と優先度:
SIPシグナリングとメディアトラフィックは異なる性質を持ち、異なるQoS（Quality of Service）要件があります。シグナリングメッセージはリアルタイム性が求められますが、メディアストリームほどの厳密な遅延要件ではないことが多いです。
対策: ネットワーク機器でDiffServ (DSCP) などのQoSマーキングを用いて、SIPシグナリングとメディアトラフィックに適切な優先度を割り当て、キューイング戦略を適用します。システム内部のメッセージキューでも優先度制御を考慮します。
SIPトランザクションとダイアログの状態管理:
INVITEはSIPにおいて最も複雑なトランザクションであり、多くのステートとタイマー（T1, T2, T4など）を伴います。正確な状態遷移の実装が不可欠です。
ダイアログはセッション全体の状態を管理し、後続のメッセージ（BYE、re-INVITEなど）が正しくルーティングされ、処理されるために重要です。
対策: RFC 3261のステートマシン定義に厳密に従い、タイマーイベントやメッセージ受信イベントに応じた正確な状態遷移ロジックを実装します。
まとめ
SIP INVITEとSDP Offer/Answerモデルは、IPベースのリアルタイム通信においてセッションを確立し、そのメディア特性を動的にネゴシエートするための基盤となるメカニズムです。RFC 3261（SIP）とRFC 3264（SDP Offer/Answer）によって詳細に定義されており、発信者がINVITEメッセージでSDP Offerを提示し、着信者が200 OK応答でSDP Answerを返すことで、メディアセッションのパラメータが合意されます。
このモデルは、柔軟なセッション確立、多様なメディア種別のサポート、中間プロキシによる拡張性といった目標を達成しています。実装においては、セキュリティ（盗聴、改ざん、なりすまし、DoS攻撃、ダウングレード攻撃、キー更新）や、ネットワーク環境（MTU、HOL blocking）、システム内部の処理（キュー制御、状態管理）に対する深い理解と適切な対策が不可欠です。これらのプロトコルは、VoIPやユニファイドコミュニケーションの進化を支える重要な要素であり続けています。
コメント