SIPプロトコルの基本とセッション管理

Tech

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

SIPプロトコルの基本とセッション管理

背景

Session Initiation Protocol (SIP) は、VoIP（Voice over IP）やマルチメディア通信において、セッションの確立、変更、および終了を行うためのシグナリングプロトコルです。インターネット上でのリアルタイム通信の需要が高まる中で、シンプルで拡張性の高いSIPは、H.323のような従来のプロトコルに代わり、現代の通信基盤の核となっています。

SIPは、Internet Engineering Task Force (IETF) によって標準化され、その中核はRFC 3261「SIP: Session Initiation Protocol」で定義されています。このプロトコルは、メディアストリーム自体を制御するリアルタイム転送プロトコル（RTP）や、メディアセッションの内容を記述するセッション記述プロトコル（SDP: RFC 4566）と連携して機能します。

設計目標

SIPの主な設計目標は以下の通りです。

  • シンプルさ: HTTPに類似したテキストベースのメッセージフォーマットを採用し、理解と実装を容易にする。

  • 拡張性: 新しい機能やヘッダフィールドを容易に追加できる柔軟なフレームワークを提供する。

  • 分散性: 中央集権的な制御を必要とせず、サーバー間の分散協調を可能にする。

  • 信頼性: トランザクション層でメッセージの信頼性（再送メカニズム）を確保する。

  • ユーザーモビリティ: ユーザーの位置に関わらず、パーソナルな接続性を確保する。

詳細

SIPの基本要素

SIPネットワークは、以下の主要なコンポーネントで構成されます。

  • ユーザーエージェント (User Agent, UA): SIPエンドポイント。ユーザーエージェントクライアント (UAC) とユーザーエージェントサーバー (UAS) の両方の機能を持つ。

    • UAC: SIPリクエストを開始するエンティティ。

    • UAS: SIPリクエストを受け取り、応答を返すエンティティ。

  • プロキシサーバー (Proxy Server): SIPリクエストを転送し、ルーティング判断を行う。ステートレスプロキシとステートフルプロキシがある。

  • レジストラーサーバー (Registrar Server): UACの現在の場所情報をユーザーエージェントロケーターサービスに登録する。

  • リダイレクトサーバー (Redirect Server): UACに対して、リクエストを転送すべき次のホップのURIを返す。

SIPメッセージ構造

SIPメッセージはHTTPに類似したテキストベースのフォーマットを持ち、リクエストとレスポンスの2種類があります。

リクエストメッセージ

メソッド、リクエストURI、SIPバージョン、および各種ヘッダフィールドから構成されます。

INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Alice <sip:alice@example.com>
From: Bob <sip:bob@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.org
CSeq: 314159 INVITE
Contact: <sip:bob@pc33.example.org>
Content-Type: application/sdp
Content-Length: 142

(SDPボディ)

主なSIPメソッド:

  • INVITE: セッション確立を開始する。

  • ACK: INVITEに対する最終応答を確認する。

  • BYE: セッションを終了する。

  • CANCEL: 進行中のリクエストを取り消す。

  • OPTIONS: UAの機能やサポートするメソッドを照会する。

  • REGISTER: UAの現在の連絡先（IPアドレスとポート）をレジストラーに登録する。

  • SUBSCRIBE/NOTIFY: イベント通知を購読/通知する。

レスポンスメッセージ

SIPバージョン、ステータスコード、理由フレーズ、および各種ヘッダフィールドから構成されます。

  • 1xx (Provisional): 暫定応答（例: 100 Trying, 180 Ringing, 183 Session Progress）

  • 2xx (Success): 成功（例: 200 OK）

  • 3xx (Redirection): リダイレクト（例: 302 Moved Temporarily）

  • 4xx (Client Error): クライアントエラー（例: 404 Not Found, 407 Proxy Authentication Required）

  • 5xx (Server Error): サーバーエラー（例: 500 Server Internal Error）

  • 6xx (Global Failure): グローバルな失敗（例: 600 Busy Everywhere）

セッション管理フロー

SIPにおけるセッション管理は、主に「トランザクション」と「ダイアログ」という二つの概念に基づいています。

  • トランザクション: 1つのリクエストとそれに対する1つ以上のレスポンスの交換。例えば、INVITEリクエストとその最終応答（200 OKやエラー）まで。

  • ダイアログ: 2つのUA間で確立されるピアツーピアの関係。Call-ID、Toヘッダタグ、Fromヘッダタグによって一意に識別され、セッション期間中の後続のリクエスト（ACK, BYE, re-INVITEなど）のコンテキストを提供する。

基本的な呼設定（握手）

SIPセッションの確立は、INVITE-200 OK-ACKの3ウェイハンドシェイクによって行われます。SDPは、INVITE（または183 Session Progress）と200 OKのボディに含まれ、メディア能力の交換とネゴシエーションに使用されます。

sequenceDiagram
    participant "UAC as ユーザーA (UAC)"
    participant Proxy as プロキシサーバー
    participant "UAS as ユーザーB (UAS)"

    UAC ->> Proxy: INVITE sip:userB@example.com | セッション開始要求 (SDP Offer)
    Proxy ->> UAS: INVITE sip:userB@example.com
    UAS -->> Proxy: SIP/2.0 100 Trying | 試行中
    Proxy -->> UAC: SIP/2.0 100 Trying
    UAS -->> Proxy: SIP/2.0 180 Ringing | 着信中
    Proxy -->> UAC: SIP/2.0 180 Ringing
    UAS -->> Proxy: SIP/2.0 200 OK | 成功 (SDP Answer)
    Proxy -->> UAC: SIP/2.0 200 OK
    UAC ->> UAS: ACK | 200 OK確認
    Note right of UAC: RTPメディアストリーム確立
    UAC> UAS: RTP | 音声/映像通信

セッション終了

セッションの終了は、いずれかのUAがBYEリクエストを送信することで行われます。

sequenceDiagram
    participant "UAC as ユーザーA (UAC)"
    participant "UAS as ユーザーB (UAS)"

    UAC ->> UAS: BYE sip:userB@example.com | セッション終了要求
    UAS -->> UAC: SIP/2.0 200 OK | 終了確認
    Note right of UAC: RTPメディアストリーム終了

再送と0-RTTに関する考慮事項

SIPプロトコル自体には、TLS 1.3のような0-RTT（ゼロラウンドトリップタイム）の概念は直接存在しません。しかし、以下のように関連するメカニズムや考慮点があります。

  • 再送: SIPはUDPとTCPの両方のトランスポートプロトコルをサポートします。UDPを使用する場合、SIPはアプリケーション層で信頼性を確保するために、INVITEなどのメッセージに対してT1、T2、T4といったタイマーに基づいた再送メカニズム（RFC 3261, Section 17）を持ちます。これにより、ネットワークのパケットロスがあってもトランザクションの完了を試みます。sequenceDiagramで表現すると、一定時間応答がない場合にリクエストが再送される形になります。

  • 0-RTTの再送リスク: SIPシグナリングがTLS 1.3上で動作する場合、TLS 1.3の0-RTTハンドシェイク（Early Data）は、初回接続時にクライアントがデータ（例えば、SIP INVITEメッセージの一部）を0-RTTで送信できる機能です。これはセッション確立のレイテンシを大幅に削減しますが、リプレイアタックのリスクを伴います。SIPプロトコル自体は0-RTTデータを意識しませんが、基盤となるTLSレイヤーでリプレイ保護メカニズム（One-time PadやAnti-Replayトークンなど）が適切に実装されていることを確認する必要があります。SIPメッセージのペイロードは状態変更を引き起こす可能性があるため、0-RTT Early Dataでの送信は慎重に扱うべきです。

ヘッダ/パケット構造（SIPメッセージ例）

SIPはテキストベースのため、ヘッダはフィールド名と値で構成されます。UDP/TCPパケットのペイロードとして直接格納されます。

SIPメッセージ構造の概要:
  Request-Line / Status-Line
  Message-Header (フィールド名: 値)
    Via:bits (SIPパス情報)
    From:bits (送信元)
    To:bits (宛先)
    Call-ID:bits (ダイアログ識別子)
    CSeq:bits (トランザクション識別子/順序)
    Contact:bits (UAの直接的な連絡先)
    Content-Type:bits (メッセージボディのタイプ)
    Content-Length:bits (メッセージボディの長さ)
  CRLF
  Message-Body (SDPなど)

各フィールドの長さは可変であり、特定のビット長を持つのではなく、UTF-8エンコードされたテキストとして解釈されます。

相互運用

既存プロトコルとの比較

  • SIP vs H.323:

    • SIP: テキストベース、HTTPに似た構造、シンプル、拡張性高い、分散型アーキテクチャ。IETF標準。

    • H.323: バイナリベース、複雑、集中型（ゲートキーパーが必須）、コンポーネント間の密結合。ITU-T標準。

  • SIP vs HTTP:

    • 共通点: テキストベース、リクエスト/レスポンスモデル、ヘッダとボディの構造、URIによるリソース識別。

    • 相違点: SIPはセッション管理に特化（ステートレス/ステートフルなトランザクションとダイアログの概念）、HTTPはWebリソースの取得・操作に特化（基本ステートレス）。SIPはUDPもサポートするが、HTTPは通常TCP。

NAT/ファイアウォール越え

SIPはNATやファイアウォールを直接越えるメカニズムを持たないため、以下の補助プロトコルが不可欠です。

  • STUN (Session Traversal Utilities for NAT): RFC 5389で定義。自身のパブリックIPアドレスとポートをNATの背後から発見する。

  • TURN (Traversal Using Relays around NAT): RFC 8656で定義。STUNで解決できない複雑なNAT環境（対称NATなど）で、メディアをリレーサーバー経由で転送する。

  • ICE (Interactive Connectivity Establishment): RFC 8839で定義。STUNとTURNを組み合わせて、ピア間で最適なパスを見つけるためのフレームワーク。

セキュリティ考慮

SIP通信は、多くの潜在的なセキュリティリスクに直面します。

  • 認証:

    • Digest認証: SIPはHTTP Digest認証（RFC 2617を参考にRFC 3261に統合）を利用して、ユーザーの認証とメッセージの完全性を確保します。パスワードがネットワーク上を平文で流れるのを防ぎます。

  • 機密性:

    • TLS (Transport Layer Security): SIPシグナリング（メッセージ）の盗聴を防ぐため、TLS（例: SIP over TLS）を使用します。

    • SRTP (Secure Real-time Transport Protocol): メディアストリーム（RTP）の盗聴、改ざん、リプレイ攻撃を防ぐために、SRTP (RFC 3711) を使用します。

  • リプレイアタック:

    • CSeqヘッダのシーケンス番号やDigest認証のNonce値を用いることで、過去の有効なSIPメッセージが再利用されるリプレイアタックを防ぎます。

  • ダウングレードアタック:

    • 攻撃者が暗号化された通信（TLS/SRTP）を暗号化されていない通信（TCP/RTP）に強制的にダウングレードさせようとする攻撃です。プロトコル実装は、より安全なトランスポートを優先し、ダウングレード要求を拒否するように設定されるべきです。

  • キー更新:

    • SRTPの暗号化キーは定期的に更新されるべきです。DTLS-SRTPやSDES (Session Description Protocol Security Descriptions for Media Streams) などの鍵管理プロトコルを利用して、セキュアな鍵交換と更新を行います。

  • 0-RTTの再送リスク:

    • 前述の通り、基盤のTLS 1.3で0-RTT Early Dataを使用する場合、リプレイ攻撃のリスクがあります。SIP実装者は、TLSレイヤーでのリプレイ保護が適切に行われていることを確認し、状態変更を引き起こす可能性のあるSIPメソッド（例: INVITE）を0-RTT Early Dataで送信する際は特に注意が必要です。

実装メモ

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

  • MTU / Path MTU: UDPトランスポートを使用する場合、大きなSIPメッセージ（特にSDPを含む場合）は、ネットワークのMTUを超えることがあります。IPフラグメンテーションは信頼性が低いため、SIPメッセージがPath MTUを超えないように、SIPスタックでサイズを考慮するか、TCPトランスポートを検討する必要があります。

  • HOL blocking回避: SIPが単一のTCP接続で複数の独立したトランザクションを処理する場合、TCPのヘッドオブラインブロッキング（HOL blocking）が発生する可能性があります。これは、ネットワークの輻輳によって、あるSIPメッセージがブロックされると、後続のすべてのメッセージもブロックされる現象です。これを回避するために、複数のTCP接続を使用するか、アプリケーション層でメッセージの優先度付けとキュー制御を行うことが重要です。

  • キュー制御と優先度: SIPシグナリングとRTPメディアストリームは異なる品質要求を持ちます。SIPメッセージの処理キューは、リアルタイム性の高いRTPトラフィックに影響を与えないように適切に管理されるべきです。QoS（Quality of Service）メカニズムを利用して、優先度を割り当てることを検討します。

  • 状態管理の複雑さ: SIPプロキシはステートレスまたはステートフルにできますが、ダイアログの状態管理はUAにとって複雑なタスクです。Call-ID、Toタグ、Fromタグによって一意に識別されるダイアログの状態を正確に追跡し、後続のインダイアログリクエストを適切に処理する必要があります。

まとめ

SIPプロトコルは、RFC 3261を中心とした一連の標準文書によって定義され、現代のリアルタイムマルチメディア通信の中核を担っています。そのテキストベースのシンプルさ、拡張性、分散型アーキテクチャは、VoIPやユニファイドコミュニケーションの普及に大きく貢献しました。

SIPのセッション管理は、INVITE-200 OK-ACKのような明確なハンドシェイクによってセッションを確立し、BYEによって終了させます。実用的な展開には、RFC 4566のSDPによるメディア記述、そしてNAT越えのためのSTUN (RFC 5389)、TURN (RFC 8656)、ICE (RFC 8839) の統合が不可欠です。セキュリティ面では、Digest認証、TLS、SRTPを用いて、認証、機密性、完全性を確保し、リプレイやダウングレード攻撃に対処する必要があります。

実装においては、MTU、HOLブロッキング、キュー制御、そして複雑な状態管理といった課題への注意が必要です。これらの考慮事項を適切に処理することで、堅牢で効率的なSIPベースの通信システムを構築できます。

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

コメント

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