RFC 3261 SIPプロトコル概要

RFC 3261で定義されるSession Initiation Protocol (SIP) は、IPネットワーク上でマルチメディアセッションを確立、変更、および終了するためのシグナリングプロトコルである。

背景

インターネットの普及に伴い、IPネットワーク上での音声通話、ビデオ会議、インスタントメッセージングなどのリアルタイム通信の需要が増大した。従来の電話網とは異なるIPベースの柔軟な通信インフラを構築するため、セッション管理と参加者のルーティング、能力ネゴシエーションを担うシグナリングプロトコルが必要とされた。RFC 3261 SIPは、この課題に対し、HTTPに類似したシンプルかつ拡張性の高いフレームワークを提供するためにIETFによって策定された。

設計目標

SIPの設計目標は以下の通りである。

• シンプルさ: プロトコル自体の複雑性を最小限に抑え、HTTPに似たテキストベースのメッセージングを採用。
• スケーラビリティ: 大規模なユーザーベースとネットワーク環境に対応できるアーキテクチャ。
• 拡張性: 新しいサービスや機能、メディアタイプを容易に追加できるフレームワーク。
• 信頼性: メッセージの信頼性のある転送と、ネットワーク障害時の回復メカニズム。
• 柔軟性: ピアツーピアおよびプロキシベースのルーティングの両方に対応。
• メディア独立性: シグナリングとメディア転送（RTP/RTCPなど）を分離し、様々なメディアタイプをサポート。

詳細

SIPのアーキテクチャは、User Agent (UA)、Proxy Server、Redirect Server、Registrar Serverといったコンポーネントで構成される。UAは通信のエンドポイントであり、クライアント (UAC) とサーバー (UAS) の両方の役割を果たす。

SIPメッセージはHTTPと同様に、Start-Line、Header Fields、Message Bodyから構成されるテキストベースのフォーマットを使用する。

SIPメッセージ構造

SIP Message Structure:
  Start-Line: variable_length_text (例: INVITE sip:user@example.com SIP/2.0)
  Header-Fields:
    Via: variable_length_text (例: Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKabc)
      protocol_name: variable_length_string
      protocol_version: variable_length_string
      transport: variable_length_string
      sent_by_host: variable_length_string (IPアドレスまたはホスト名)
      sent_by_port: integer
      branch_parameter: variable_length_string (トランザクション識別子)
    From: variable_length_text (例: From: "Alice" <sip:alice@example.com>;tag=123)
    To: variable_length_text (例: To: "Bob" <sip:bob@example.com>)
    Call-ID: variable_length_text (例: Call-ID: 55667788@192.0.2.1)
    CSeq: integer SP method (例: CSeq: 1 INVITE)
    Content-Type: variable_length_text (例: Content-Type: application/sdp)
    Content-Length: integer (メッセージボディのオクテット長)
  Empty-Line: CRLF
  Message-Body: variable_length_text (例: SDPペイロード)

基本フロー（INVITEメソッドによるセッション確立）

典型的なSIPセッション確立フローは以下のようになる。

sequenceDiagram
    participant "UAA as User Agent A"
    participant "Proxy as SIP Proxy Server"
    participant "UAB as User Agent B"

    UAA ->> Proxy: INVITE sip:bob@example.com SIP/2.0
    Proxy ->> UAB: INVITE sip:bob@example.com SIP/2.0
    UAB -->> Proxy: SIP/2.0 180 Ringing
    Proxy -->> UAA: SIP/2.0 180 Ringing
    UAB -->> Proxy: SIP/2.0 200 OK (SDP)
    Proxy -->> UAA: SIP/2.0 200 OK (SDP)
    UAA ->> UAB: ACK sip:bob@example.com SIP/2.0
    Note over UAA,UAB: RTP/RTCP Media Stream (Direct)
    UAA ->> UAB: BYE sip:bob@example.com SIP/2.0
    UAB -->> UAA: SIP/2.0 200 OK

• INVITE: セッション確立要求を送信。
• 180 Ringing: 呼び出し中を通知。
• 200 OK: セッション確立成功。通常、メディアセッションの記述をRFC 4566 SDP (Session Description Protocol) 形式でメッセージボディに含める。
• ACK: INVITEに対する最終応答 (2xx) の受信確認。ACKはINVITEと異なるトランザクションとして扱われ、メディアセッションの確立を完了する。
• BYE: セッション終了要求。

相互運用

SIPは、リアルタイム通信環境において他のプロトコルと密接に連携する。

• HTTP: SIPはHTTP/1.1の要求/応答モデル、ヘッダーフォーマット、ステータスコードの概念を継承している。URIスキームの利用や認証メカニズム（Digest認証）も共通点が多い。
• H.323:
  • SIPはテキストベースでモジュール性が高く、主にIETFによって推進される。H.323はバイナリベースでよりモノリシックなプロトコルスタックを持ち、ITU-Tによって推進された。
  • SIPはプロキシサーバーベースのルーティングを基本とし柔軟。H.323はゲートキーパーを中心とした集中型アーキテクチャ。
  • SIPはプロトコルがシンプルで実装しやすく、Webとの親和性が高い。
• SDP (RFC 4566): SIPメッセージのボディで、メディアセッション（コーデック、IPアドレス、ポート番号など）の詳細を記述するために使用される。
• RTP/RTCP (RFC 3550): SIPによって確立されたセッションの実際のリアルタイムメディア（音声、ビデオ）転送に使用される。
• DNS (RFC 1034/1035): SIPサーバーの発見には、特にRFC 2782 SRVレコードが利用される。

セキュリティ

SIPは、以下のセキュリティ脅威に対して対策を講じている。

• 認証:
  • Digest認証 (RFC 7617): HTTP Digest認証の仕組みを継承し、ユーザー名とパスワードをネットワーク上で直接送信することなく認証を行う。リプレイ攻撃のリスクを軽減するため、サーバーから提供されるnonce値が利用される。
  • TLSクライアント証明書: より強力な認証が必要な場合、SIP over TLS (SIPS) 環境下でクライアント証明書を利用できる。
• 機密性/完全性:
  • SIP over TLS (SIPS): SIPメッセージ自体をTLS (Transport Layer Security) で保護することで、盗聴や改ざんを防ぐ。sips: URIスキームを使用すると、TLSの使用が強制される。
  • SRTP (Secure Real-time Transport Protocol): RFC 3711で定義され、メディアストリーム（RTPパケット）の暗号化と認証を提供する。鍵交換はSDPの一部として行われることが多い。
• リプレイ攻撃: SIPメッセージのCSeqヘッダに含まれるシーケンス番号により、メッセージの順序を保証し、古いメッセージのリプレイを検出できる。Digest認証のnonce値もリプレイ攻撃対策に寄与する。
• ダウングレード攻撃: SIP自体に直接的なダウングレード攻撃のメカニズムは少ないが、セキュリティ機構のネゴシエーション（例：TLSの使用可否）において、保護されていない通信パスへの意図的な誘導が考えられる。sips: URIの使用を徹底することで、この種のリスクを軽減できる。
• キー更新: SRTPで利用されるセッションキーは、SDPの再ネゴシエーションを通じて、あるいはDTLS-SRTP (RFC 5764) のようなプロトコルを用いて動的に更新できる。
• 0-RTTの再送リスク: SIPのUDPトランスポートでは、トランザクションの信頼性はUser Agentがタイマーと再送メカニズムで確保する。0-RTTの概念は直接存在しないが、初期のINVITEメッセージが認証なしで送信されることがあり、攻撃者がセッション確立を試みるリスクがある。このリスクは、サーバーが401 Unauthorizedまたは407 Proxy Authentication Required応答とWWW-Authenticateヘッダを返して認証を要求するチャレンジ/レスポンスフローによって軽減される。

実装メモ

SIPプロトコルを実装する際には、以下の点に留意する必要がある。

• MTU/Path MTU: SIPメッセージ、特にSDPペイロードが大量のコーデック情報などを含む場合、メッセージサイズがMTUを超える可能性がある。UDP使用時にはIPフラグメンテーションが発生し、パケットロス耐性が低下する。TCP使用時はパフォーマンスに影響が出るため、Path MTU Discovery (PMTUD) の実装や、メッセージサイズの適切な管理が望ましい。
• HOL blocking回避: SIPは本質的にメッセージベースであり、複数の独立したトランザクションを並行して処理できるため、TCPのようなストリームベースプロトコルで懸念されるHead-of-Line (HOL) Blockingはアプリケーションレイヤでは直接的な問題とはなりにくい。ただし、SIP UAが複数のセッションを単一のTCPコネクション上で多重化する場合、アプリケーションレイヤでのキューイングと優先度制御が重要になる。
• キュー制御: SIPプロキシサーバーやUAS (User Agent Server) は、受信した多数のSIPリクエストや応答を適切にキューイングし、処理順序やリソース消費を管理する必要がある。高負荷時にはメッセージドロップや処理遅延が発生しないよう、優先度ベースのキューイングやレートリミットを実装することが求められる。
• 優先度: RFC 3261では、緊急呼 (Priorityヘッダのemergency値) など、特定のQoSが要求されるセッションに対し、SIPメッセージに優先度情報を付与することが可能である。実装では、この優先度情報に基づき、処理リソースの割り当て、ネットワークでのDSCP (Differentiated Services Code Point) 設定を通じたパケット転送の優先順位付け、およびキューイング戦略を調整する必要がある。

まとめ

RFC 3261 SIPは、IPネットワークにおけるリアルタイム通信のための堅牢で拡張性の高いシグナリングプロトコルとして確立されている。HTTPライクなシンプルさと柔軟性を持ち、SDPやRTP/RTCPといった他のプロトコルとの連携により、多種多様なメディアタイプと通信シナリオをサポートする。セキュリティ、スケーラビリティ、相互運用性に関する明確な考慮がなされており、VoIPやUC (Unified Communications) システムの基盤技術として広く利用され続けている。