SIPプロトコル (RFC 3261) 解説

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

SIPプロトコル (RFC 3261) 解説

背景

Session Initiation Protocol (SIP) は、マルチメディアセッションの確立、変更、および終端を行うためのアプリケーション層制御プロトコルです。主にIP電話やビデオ会議などのリアルタイム通信において、セッションのセットアップと管理に使用されます。RFC 3261 は、2002年6月にIETFによって公開され、SIPの主要な仕様を定義しています[1]。SIPは、HTTPと類似したテキストベースのリクエスト/レスポンスモデルを採用しており、高い拡張性と柔軟性を持っています。

設計目標

RFC 3261で定義されているSIPの設計目標は以下の通りです[1]:

  • 参加者の位置特定: ユーザーがどこにいるかに関わらず、セッションを開始できるようにする。

  • ユーザーの可用性: ユーザーが通信可能かどうか、現在の状態を判断できるようにする。

  • ユーザーの能力: ユーザーがどのようなメディアセッションをサポートできるかを判断できるようにする。

  • セッション設定: 異なるメディアタイプやプロトコルを含むセッションを確立できるようにする。

  • セッション管理: セッションの転送、変更、終了などの機能を提供する。

  • スケーラビリティ: 大規模なネットワークで動作し、多数のユーザーとセッションをサポートできること。

  • モビリティ: ユーザーがネットワーク上で移動しても、セッションを維持できること。

  • 拡張性: 将来の機能追加や新しいサービスに対応できる柔軟性を持つこと。

詳細

SIPの主要な要素

SIPネットワークは、主に以下の論理エンティティで構成されます[1]:

flowchart TD
    A["User Agent Client (UAC)"] -->|INVITE| B{"Proxy Server"}
    B -->|INVITE| C{"Registrar Server"}
    C -->|REGISTER| D["User Agent Server (UAS)"]
    D -->|200 OK| B
    B -->|200 OK| A
    A -- INVITE-ACK --> D
    D -- BYE --> A

  • User Agent Client (UAC): SIPリクエストを開始するエンティティ。

  • User Agent Server (UAS): SIPリクエストを受信して応答するエンティティ。

    • UACとUASは合わせてUser Agent (UA)と呼ばれ、電話機やソフトウェアクライアントなどが該当します。

  • Proxy Server: UA間のリクエストを転送し、ルーティング判断を行う中間サーバー。ステートフルまたはステートレスで動作します。

  • Registrar Server: ユーザーの現在地情報（IPアドレスなど）をデータベースに登録するサーバー。

  • Redirect Server: リクエストを処理するUAの代替URIを通知し、クライアントに直接再接続させるサーバー。

SIPメッセージの構造

SIPメッセージはHTTPと同様にテキストベースであり、メソッド、URI、プロトコルバージョンから始まるスタートライン、ヘッダフィールド、そしてオプションのメッセージボディで構成されます[1]。メッセージボディには通常、Session Description Protocol (SDP) が含まれ、セッションで使用するメディアタイプ、コーデック、IPアドレス、ポート番号などが記述されます。

Request-Line / Status-Line (例: INVITE sip:user@example.com SIP/2.0)
Header-Field: Value
...
Header-Field: Value
(空行)
Message-Body (SDPなど)

代表的なヘッダフィールド:

  • Via: メッセージが経由したパスを記録。再送検出やループ防止に利用。

  • From: リクエストを開始したユーザーのURI。

  • To: リクエストの最終的な受信者のURI。

  • Call-ID: 単一のセッションまたはダイアログを一意に識別するID。

  • CSeq: リクエストのシーケンス番号。再送とリクエストの順序付けに使用。

  • Contact: UAの現在の到達可能なURI。

  • Max-Forwards: リクエストが経由できるホップ数の上限。

  • Content-Type: メッセージボディのメディアタイプ。

  • Content-Length: メッセージボディのバイト長。

SIPセッション確立の流れ (INVITEトランザクション)

SIPでは、クライアントがUASから信頼性の高い応答を受け取ることを保証するためにトランザクションが定義されています。最も基本的な呼設定のシーケンスは以下の通りです。

sequenceDiagram
    participant "UAC as User Agent Client"
    participant "Proxy as Proxy Server"
    participant "UAS as User Agent Server"

    UAC ->> Proxy: INVITE sip:bob@example.com (セッション開始リクエスト)
    Proxy ->> UAS: INVITE sip:bob@example.com
    UAS -->> UAS: 100 Trying (試行中、任意)
    UAS -->> UAS: 180 Ringing (着信中、任意)
    UAS ->> Proxy: 200 OK (応答、SDP含む)
    Proxy ->> UAC: 200 OK (応答、SDP含む)
    UAC ->> UAS: ACK (最終確認、SDP交換完了)
    Note over UAC,UAS: RTP/RTCPによるメディア通信
    UAC ->> UAS: BYE (セッション終了リクエスト)
    UAS ->> UAC: 200 OK (BYE応答)

  1. INVITE: UACはUASにセッション確立を要求するINVITEリクエストを送信。

  2. 1xx応答 (Provisional Response): UASは呼の進行状況を示す一時的な応答 (例: 100 Trying, 180 Ringing) を送信。

  3. 200 OK (Success Response): UASはセッション確立に成功したことを示す200 OK応答を送信。これにはセッションに関するSDPが含まれる。

  4. ACK: UACは200 OK応答を受信したことを確認するため、ACKリクエストを送信。これにより、INVITEトランザクションは完了し、ダイアログが確立する。

  5. メディア通信: UACとUASは、SDPで合意されたパラメータに基づいてRTP (Real-time Transport Protocol) を使用してメディア通信を開始。

  6. BYE: セッションを終了したいUACまたはUASはBYEリクエストを送信。

  7. 200 OK (BYE): BYEを受信した側は200 OKで応答し、セッションが終了。

相互運用性

HTTPとの比較

SIPはHTTPと多くの点で類似していますが、異なる目的のために設計されています。

  • 類似点:

    • テキストベースのメッセージフォーマット。

    • リクエスト/レスポンスモデル。

    • URI (Uniform Resource Identifier) を使用してリソースを識別。

    • ヘッダフィールドの構造が類似。

  • 相違点:

    • 目的: HTTPはWebコンテンツの取得や操作が主な目的である一方、SIPはリアルタイムセッションの確立と管理に特化。

    • 状態: HTTPは通常ステートレスだが、SIPは「ダイアログ」という概念を持ち、セッションの間は状態を維持する（ステートフル）。

    • プロトコル: SIPは通常UDP上で動作することも多く、再送処理をアプリケーション層で持つ。HTTP/1.1はTCPのみ。

    • メソッド: HTTPのGET/POSTなどに対し、SIPはINVITE/ACK/BYE/REGISTERなど。

    • 信頼性: SIPはUDPを使用する場合、トランザクション層で再送メカニズムを持つ。

その他のプロトコルとの連携

  • SDP (RFC 4566): SIPはSDPをメッセージボディに含めることで、メディアセッションの詳細（コーデック、帯域幅、ポートなど）を記述・交換します。これにより、両端のUAが互いに互換性のあるメディアパラメータを合意できます。

  • RTP/RTCP (RFC 3550): SIPがセッションを確立した後、実際の音声や映像などのリアルタイムメディアデータはRTPで送信されます。RTCPはRTPセッションの品質管理や統計情報を提供します。

  • UDP/TCP: SIPは、信頼性の低いUDPと信頼性の高いTCPの両方で動作可能です。UDPはオーバーヘッドが少なく高速ですが、メッセージの再送や順序付けはSIPレイヤーで行う必要があります。TCPは信頼性を提供しますが、セットアップのオーバーヘッドが増えます。

セキュリティ考慮事項

RFC 3261は、SIPにおけるさまざまなセキュリティ脅威と、それらに対処するためのメカニズムを定義しています[1, 2]。

  • 認証:

    • Digest認証 (RFC 2617): HTTP Digest認証と同様に、ユーザー名とパスワードのハッシュ値を用いて認証を行います。これにより、平文パスワードの漏洩を防ぎ、リプレイ攻撃を防ぐためのnonceを使用します。

    • TLS (Transport Layer Security): SIPメッセージをTCP上で送信する際にTLSを使用することで、盗聴や改ざんから通信を保護します。UA間のTLS接続を確立することで、メッセージ全体の機密性と完全性を保証します。

  • メッセージの完全性:

    • S/MIME (Secure/Multipurpose Internet Mail Extensions): メッセージボディや特定のヘッダフィールドを暗号化・署名することで、メッセージの改ざんを検出し、否認防止を提供します。

    • TLS: TLSを使用すると、転送中のSIPメッセージの完全性が確保されます。

  • 機密性:

    • S/MIME: メッセージボディを暗号化することで、コンテンツの機密性を保護します。

    • TLS: TLSは、シグナリングパス全体の機密性を提供します。

    • SRTP (Secure Real-time Transport Protocol): SIPで交換されるSDPを介してSRTP鍵を交換し、実際のメディアストリームを暗号化することで、音声や映像の盗聴を防ぎます。

  • リプレイ攻撃:

    • SIPのCSeqヘッダフィールドは、リクエストのシーケンス番号を提供し、古いリクエストのリプレイを検出するのに役立ちます。Digest認証のnonceもリプレイ保護に利用されます。

  • ダウングレード攻撃:

    • TLSの使用を強制することで、非暗号化接続へのダウングレード攻撃を防ぎます。RequireヘッダやProxy-Requireヘッダでセキュリティメカニズムの利用を要求することが可能です。

  • 0-RTTの再送リスク:

    • SIP自体にはQUICのような0-RTTハンドシェイクの概念は直接適用されません。SIPのセッション確立は複数回のメッセージ交換を必要とします。セキュリティコンテキストの再利用による遅延削減は、TLSセッション再開（TLS Session Resumption）によって実現できますが、これはSIPプロトコルそのものの機能ではなく、基盤となるTLSの機能です。TLS Session Resumptionを利用する際も、セッションチケットの安全性や再利用のポリシーを慎重に設計する必要があります。

実装メモ

SIP実装には、以下の点に注意が必要です。

  • NAT/ファイアウォールトラバーサル: SIPはIPアドレスとポート番号をメッセージ内で頻繁に利用するため、NATやファイアウォールを越える際に問題が発生しやすいです。ICE (Interactive Connectivity Establishment)、STUN (Session Traversal Utilities for NAT)、TURN (Traversal Using Relays around NAT) などの技術と連携させることで解決が図られます。これらはRFC 3261のスコープ外ですが、現代のSIPシステムには不可欠です。

  • MTU/Path MTU: 特にUDPを使用する場合、SIPメッセージがPath MTUを超えることがないように注意が必要です。メッセージが大きすぎる場合、IPフラグメンテーションが発生し、パケットロスやパフォーマンス低下につながる可能性があります。Path MTU Discovery (PMTUD) はIPレベルで機能しますが、SIPアプリケーションがメッセージサイズを適切に管理することも重要です。

  • HOL blocking (Head-of-Line Blocking): SIPをTCP上で実装する場合、TCPのHOL blockingの影響を受ける可能性があります。複数のSIPトランザクションが単一のTCP接続上で処理されると、前のトランザクションの処理が遅れることで後続のトランザクションがブロックされる可能性があります。UDPまたは複数のTCP接続を利用することでこれを回避できます。

  • キュー制御と優先度: プロキシサーバーなどでは、大量のSIPリクエストを効率的に処理するために、リクエストのキューイングと優先度付けのメカニズムが必要です。特に、INVITEのような呼設定リクエストは優先度を高くし、帯域幅の枯渇を防ぐ必要があります。

  • 信頼性メカニズム: SIPはUDP上で動作する場合でも、INVITEトランザクションの再送タイマー（T1, T2など）やCSeqヘッダを利用してメッセージの信頼性と順序性を確保します。これらのタイマー設定はネットワーク環境に合わせて適切に調整する必要があります。

  • フォーク (Forking): 複数の場所でユーザーにリーチするために、プロキシがINVITEリクエストを複数のUAに同時に転送するフォーク機能の実装を考慮する必要があります。

まとめ

SIP (RFC 3261) は、リアルタイム通信セッションの確立、変更、終端を可能にする強力で柔軟なプロトコルです。そのテキストベースの構造とHTTPに似たリクエスト/レスポンスモデルは、拡張性と相互運用性を提供します。セキュリティ面では、Digest認証、TLS、S/MIME、SRTPなどを用いて認証、機密性、完全性を確保するメカニズムが定義されています。実装においては、NATトラバーサルやMTU、信頼性メカニズムの適切な管理が、安定したサービス提供のために不可欠です。ネットワークエンジニアとしてSIPを扱う際には、これらの側面を深く理解することが求められます。

[1] J. Rosenberg et al. (June 2002). “SIP: Session Initiation Protocol”. IETF RFC 3261. URL: https://datatracker.ietf.org/doc/html/rfc3261 (Accessed: {{jst_today}}). [2] J. Rosenberg et al. (June 2002). “Section 26 Security Considerations” in “SIP: Session Initiation Protocol”. IETF RFC 3261. URL: https://datatracker.ietf.org/doc/html/rfc3261#section-26 (Accessed: {{jst_today}}).

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました