SIP (Session Initiation Protocol)
基本情報
SIP（Session Initiation Protocol）は、音声、ビデオ、インスタントメッセージングを含むマルチメディアセッションを確立、変更、終了するために広く使用されるシグナリングおよびコール制御プロトコルです。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およびマルチメディア通信における人気のある選択肢となっています。
SIPメソッド
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メソッドはユーザーエージェントがサーバーにイベント状態情報を公開するために使用され、他の関係者が利用できるようにします。
SIPレスポンスコード
1xx（Provisional Responses）：これらの応答はリクエストが受信され、サーバーが引き続き処理していることを示します。
100 Trying：リクエストが受信され、サーバーが処理中です。
180 Ringing：被呼者が警告され、通話を受けます。
183 Session Progress：通話の進行状況に関する情報を提供します。
2xx（Successful Responses）：これらの応答はリクエストが正常に受信、理解、および受け入れられたことを示します。
200 OK：リクエストが成功し、サーバーがそれを達成しました。
202 Accepted：リクエストは処理のために受け入れられましたが、まだ完了していません。
3xx（Redirection Responses）：これらの応答は、リクエストを達成するために追加のアクションが必要であり、通常は別のリソースに連絡することによって行われます。
300 Multiple Choices：複数のオプションが利用可能であり、ユーザーまたはクライアントが1つを選択する必要があります。
301 Moved Permanently：要求されたリソースには新しい恒久的URIが割り当てられています。
302 Moved Temporarily：要求されたリソースは一時的に別のURIで利用可能です。
305 Use Proxy：リクエストを指定されたプロキシに送信する必要があります。
4xx（Client Error Responses）：これらの応答は、リクエストに悪い構文が含まれているか、サーバーによって達成できないことを示します。
400 Bad Request：リクエストが誤って形成されたか無効です。
401 Unauthorized：リクエストにはユーザー認証が必要です。
403 Forbidden：サーバーはリクエストを理解しましたが、それを達成することを拒否します。
404 Not Found：要求されたリソースがサーバー上で見つかりませんでした。
408 Request Timeout：サーバーは、待機する時間内に完全なリクエストを受信しませんでした。
486 Busy Here：被呼者は現在忙しく、通話を受けることができません。
5xx（Server Error Responses）：これらの応答は、サーバーが有効なリクエストを達成できなかったことを示します。
500 Internal Server Error：サーバーはリクエストの処理中にエラーが発生しました。
501 Not Implemented：サーバーはリクエストを達成するために必要な機能をサポートしていません。
503 Service Unavailable：サーバーは現在、メンテナンスまたは過負荷のためにリクエストを処理できません。
6xx（Global Failure Responses）：これらの応答は、リクエストをどのサーバーも達成できないことを示します。
600 Busy Everywhere：通話のすべての可能な宛先が使用中です。
603 Decline：被呼者は通話に参加したくないです。
604 Does Not Exist Anywhere：要求されたリソースはネットワークのどこにも存在しません。
例
SIP INVITEの例
SIP REGISTERの例
REGISTERメソッドは、Session Initiation Protocol（SIP）で使用され、ユーザーエージェント（UA）（例：VoIP電話またはソフトフォン）がSIP登録サーバーにその位置を登録することを可能にします。このプロセスにより、サーバーは登録されたユーザー宛の着信SIPリクエストをどこにルーティングするかを知ることができます。登録サーバーは通常、SIPプロキシサーバーまたは専用の登録サーバーの一部です。
以下は、REGISTER認証プロセスに関与するSIPメッセージの詳細な例です：
UAから登録サーバーへの初期REGISTERリクエスト：
この最初のREGISTERメッセージは、UA（Alice）から登録サーバーに送信されます。これには、希望する登録期間（Expires）、ユーザーのSIP URI（sip:alice@example.com）、およびユーザーのコンタクトアドレス（sip:alice@192.168.1.100:5060）など、重要な情報が含まれています。
登録サーバーからの401 Unauthorized応答:
Registrarサーバーは、「401 Unauthorized」メッセージで応答し、その中に「WWW-Authenticate」ヘッダーが含まれます。このヘッダーには、UAが自分自身を認証するために必要な情報が含まれており、認証領域、ナンス、およびアルゴリズムなどが含まれています。
認証情報を使用したREGISTERリクエスト:
UAは別のREGISTERリクエストを送信し、今回はユーザー名、レルム、ノンス、およびユーザーのパスワードを使用して計算された応答値など、必要な資格情報を含む**"Authorization"ヘッダー**を含めます。
これがAuthorizarion応答が計算される方法です：
登録成功 レジストラーサーバーからの応答:
登録サーバーが提供された資格情報を検証した後、登録が成功したことを示すために "200 OK" レスポンスを送信します。このレスポンスには登録された連絡先情報と登録の有効期限が含まれます。この時点で、ユーザーエージェント（Alice）はSIP登録サーバーに正常に登録され、Alice宛の着信SIPリクエストは適切な連絡先アドレスにルーティングされます。
通話の例
言及されていませんが、User B はProxy 2 に REGISTER メッセージを送信してから通話を受けることができます。
Last updated
