SIP (Session Initiation Protocol)
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
SIP (Session Initiation Protocol) は、IPネットワーク上で音声、ビデオ、インスタントメッセージングを含むマルチメディアセッションを確立、変更、終了するために広く使用される シグナリングおよびコール制御プロトコルです。Internet Engineering Task Force (IETF) によって開発され、SIPはRFC 3261で定義されており、VoIPおよび統合通信の事実上の標準となっています。
SIPの主な特徴は以下の通りです：
テキストベースのプロトコル: SIPはテキストベースのプロトコルであり、人間が読みやすく、デバッグが容易です。HTTPに似たリクエスト-レスポンスモデルに基づいており、コールセッションを制御するためにINVITE、ACK、BYE、CANCELなどのメソッドを使用します。
スケーラビリティと柔軟性: SIPは非常にスケーラブルであり、小規模な展開から大規模な企業やキャリアグレードの環境まで使用できます。新しい機能で簡単に拡張でき、さまざまなユースケースや要件に適応可能です。
相互運用性: SIPの広範な採用と標準化により、異なるデバイス、アプリケーション、サービスプロバイダー間の相互運用性が向上し、さまざまなプラットフォーム間でシームレスな通信が促進されます。
モジュラー設計: SIPは、メディア伝送のための**RTP (Real-time Transport Protocol)やマルチメディアセッションを記述するためのSDP (Session Description Protocol)**など、他のプロトコルと連携します。このモジュラー設計により、異なるメディアタイプやコーデックとの柔軟性と互換性が向上します。
プロキシおよびリダイレクトサーバー: SIPは、コールルーティングを促進し、コール転送、コール転送、ボイスメールサービスなどの高度な機能を提供するために、プロキシおよびリダイレクトサーバーを使用できます。
プレゼンスおよびインスタントメッセージング: SIPは音声およびビデオ通信に限定されません。プレゼンスおよびインスタントメッセージングもサポートしており、幅広い統合通信アプリケーションを可能にします。
多くの利点があるにもかかわらず、SIPは特にNATトラバーサルやファイアウォールの問題に対処する際に構成および管理が複雑になることがあります。しかし、その多様性、スケーラビリティ、および業界全体での広範なサポートにより、VoIPおよびマルチメディア通信の人気の選択肢となっています。
RFC 3261で定義されたコアSIPメソッドには以下が含まれます：
INVITE: 新しいセッション（コール）を開始するか、既存のセッションを変更するために使用されます。INVITEメソッドは、提案されたセッションの詳細（メディアタイプ、コーデック、トランスポートプロトコルなど）を受信者に通知するために、セッション記述（通常はSDPを使用）を運びます。
ACK: INVITEリクエストに対する最終応答の受信を確認するために送信されます。ACKメソッドは、エンドツーエンドの確認を提供することにより、INVITEトランザクションの信頼性を確保します。
BYE: 確立されたセッション（コール）を終了するために使用されます。BYEメソッドは、通信を終了したいことを示すために、セッション内のいずれかの当事者によって送信されます。
CANCEL: セッションが確立される前に保留中のINVITEリクエストをキャンセルするために送信されます。CANCELメソッドは、送信者が気が変わった場合や受信者からの応答がない場合に、INVITEトランザクションを中止することを可能にします。
OPTIONS: SIPサーバーまたはユーザーエージェントの機能を照会するために使用されます。OPTIONSメソッドは、セッションを実際に確立することなく、サポートされているメソッド、メディアタイプ、または他の拡張に関する情報を要求するために送信できます。
REGISTER: ユーザーエージェントがSIPレジストラサーバーに現在の位置を登録するために使用されます。REGISTERメソッドは、ユーザーのSIP URIと現在のIPアドレスとの間の最新のマッピングを維持するのに役立ち、コールルーティングと配信を可能にします。
誰かに電話をかけるためにREGISTERを使用する必要はありません。
ただし、INVITEを実行するために、発信者が最初に認証を行う必要がある場合があり、そうでないと**401 Unauthorized**の応答を受け取ることになります。
これらのコアメソッドに加えて、他のRFCで定義されたいくつかのSIP拡張メソッドがあります：
SUBSCRIBE: RFC 6665で定義されており、SUBSCRIBEメソッドは特定のリソースの状態（ユーザーのプレゼンスやコールステータスなど）に関する通知を要求するために使用されます。
NOTIFY: RFC 6665でも定義されており、NOTIFYメソッドは、監視されているリソースの状態の変化についてサブスクライブされたユーザーエージェントに通知するためにサーバーによって送信されます。
REFER: RFC 3515で定義されており、REFERメソッドは受信者に転送を実行するか、第三者を参照するように要求するために使用されます。これは通常、コール転送シナリオで使用されます。
MESSAGE: RFC 3428で定義されており、MESSAGEメソッドはSIPユーザーエージェント間でインスタントメッセージを送信するために使用され、SIPフレームワーク内でのテキストベースの通信を可能にします。
UPDATE: RFC 3311で定義されており、UPDATEメソッドは既存のダイアログの状態に影響を与えずにセッションを変更することを可能にします。これは、進行中のコール中にコーデックやメディアタイプなどのセッションパラメータを更新するのに便利です。
PUBLISH: RFC 3903で定義されており、PUBLISHメソッドはユーザーエージェントがイベント状態情報をサーバーに公開し、他の関心のある当事者に利用可能にするために使用されます。
1xx (暫定応答): これらの応答は、リクエストが受信され、サーバーが処理を続けていることを示します。
100 Trying: リクエストが受信され、サーバーが処理中です。
180 Ringing: 呼び出し先が通知され、コールを受ける準備をしています。
183 Session Progress: コールの進行状況に関する情報を提供します。
2xx (成功応答): これらの応答は、リクエストが正常に受信され、理解され、受け入れられたことを示します。
200 OK: リクエストが成功し、サーバーがそれを満たしました。
202 Accepted: リクエストは処理のために受け入れられましたが、まだ完了していません。
3xx (リダイレクション応答): これらの応答は、リクエストを満たすためにさらなるアクションが必要であることを示します。通常は代替リソースに連絡することによってです。
300 Multiple Choices: 複数のオプションが利用可能であり、ユーザーまたはクライアントが1つを選択する必要があります。
301 Moved Permanently: リクエストされたリソースに新しい永続的なURIが割り当てられました。
302 Moved Temporarily: リクエストされたリソースは一時的に異なるURIで利用可能です。
305 Use Proxy: リクエストは指定されたプロキシに送信する必要があります。
4xx (クライアントエラー応答): これらの応答は、リクエストに不正な構文が含まれているか、サーバーによって満たすことができないことを示します。
400 Bad Request: リクエストが不正または無効でした。
401 Unauthorized: リクエストにはユーザー認証が必要です。
403 Forbidden: サーバーはリクエストを理解しましたが、満たすことを拒否します。
404 Not Found: リクエストされたリソースはサーバー上に見つかりませんでした。
408 Request Timeout: サーバーは、待機する準備ができていた時間内に完全なリクエストを受信しませんでした。
486 Busy Here: 呼び出し先は現在ビジーで、コールを受けることができません。
5xx (サーバーエラー応答): これらの応答は、サーバーが有効なリクエストを満たすことに失敗したことを示します。
500 Internal Server Error: サーバーはリクエストを処理中にエラーに遭遇しました。
501 Not Implemented: サーバーはリクエストを満たすために必要な機能をサポートしていません。
503 Service Unavailable: サーバーは現在、メンテナンスまたは過負荷のためにリクエストを処理できません。
6xx (グローバル失敗応答): これらの応答は、リクエストがどのサーバーによっても満たされないことを示します。
600 Busy Everywhere: コールのすべての可能な宛先がビジーです。
603 Decline: 呼び出し先はコールに参加したくありません。
604 Does Not Exist Anywhere: リクエストされたリソースはネットワーク内のどこにも利用できません。
REGISTERメソッドは、セッション初期化プロトコル（SIP）で、VoIP電話やソフトフォンなどのユーザーエージェント（UA）がSIPレジストラサーバーに自分の位置を登録するために使用されます。このプロセスにより、サーバーは登録されたユーザー宛ての着信SIPリクエストをどこにルーティングするかを知ることができます。レジストラサーバーは通常、SIPプロキシサーバーまたは専用の登録サーバーの一部です。
以下は、REGISTER認証プロセスに関与するSIPメッセージの詳細な例です：
UAからレジスタサーバーへの初期REGISTERリクエスト：
この初期のREGISTERメッセージは、UA（アリス）からレジストラサーバーに送信されます。これには、希望する登録期間（Expires）、ユーザーのSIP URI（sip:alice@example.com）、およびユーザーの連絡先アドレス（sip:alice@192.168.1.100:5060）などの重要な情報が含まれています。
401 Unauthorized レジストラサーバーからの応答:
レジストラサーバーは「401 Unauthorized」メッセージで応答し、これには「WWW-Authenticate」ヘッダーが含まれています。このヘッダーには、UAが自分自身を認証するために必要な情報、例えば認証レルム、ノンス、およびアルゴリズムが含まれています。
認証情報を含むREGISTERリクエスト:
UAは別のREGISTERリクエストを送信します。この時、必要な資格情報（ユーザー名、レルム、ノンス、および提供された情報とユーザーのパスワードを使用して計算されたレスポンス値）を含む"Authorization"ヘッダーを含めます。
これがAuthorizationレスポンスが計算される方法です：
成功した登録 レスポンスはレジストラサーバーから:
レジストラサーバーが提供された認証情報を確認した後、登録が成功したことを示す「200 OK」レスポンスを送信します。レスポンスには、登録された連絡先情報と登録の有効期限が含まれています。この時点で、ユーザーエージェント（アリス）はSIPレジストラサーバーに正常に登録され、アリスへの着信SIPリクエストは適切な連絡先アドレスにルーティングされます。
言及されていませんが、ユーザーBはProxy 2にREGISTERメッセージを送信する必要があります。そうしないと、通話を受けることができません。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
