SIP (Session Initiation Protocol)

Reading time: 22 minutes

基本情報

SIP (Session Initiation Protocol) は、シグナリングおよびコール制御プロトコルであり、IPネットワーク上で音声、ビデオ、インスタントメッセージングを含むマルチメディアセッションを確立、変更、終了するために広く使用されています。Internet Engineering Task Force (IETF) によって開発され、SIPはRFC 3261で定義されており、VoIPおよび統合コミュニケーションの事実上の標準となっています。

SIPの主な特徴は以下の通りです：

1. テキストベースのプロトコル: SIPはテキストベースのプロトコルであり、人間が読みやすく、デバッグが容易です。HTTPに似たリクエスト-レスポンスモデルに基づいており、コールセッションを制御するためにINVITE、ACK、BYE、CANCELなどのメソッドを使用します。
2. スケーラビリティと柔軟性: SIPは非常にスケーラブルであり、小規模な展開から大規模な企業やキャリアグレードの環境まで使用できます。新しい機能で簡単に拡張でき、さまざまなユースケースや要件に適応可能です。
3. 相互運用性: SIPの広範な採用と標準化により、異なるデバイス、アプリケーション、サービスプロバイダー間の相互運用性が向上し、さまざまなプラットフォーム間でシームレスな通信が促進されます。
4. モジュラー設計: SIPは、メディア伝送のための**RTP (Real-time Transport Protocol)やマルチメディアセッションを記述するためのSDP (Session Description Protocol)**など、他のプロトコルと連携して動作します。このモジュラー設計により、さまざまなメディアタイプやコーデックとの柔軟性と互換性が向上します。
5. プロキシおよびリダイレクトサーバー: SIPは、コールルーティングを促進し、コール転送、コール転送、ボイスメールサービスなどの高度な機能を提供するために、プロキシおよびリダイレクトサーバーを使用できます。
6. プレゼンスおよびインスタントメッセージング: SIPは音声およびビデオ通信に限定されません。プレゼンスおよびインスタントメッセージングもサポートしており、幅広い統合コミュニケーションアプリケーションを可能にします。

多くの利点があるにもかかわらず、SIPは特にNATトラバーサルやファイアウォールの問題に対処する際に構成および管理が複雑になることがあります。しかし、その多様性、スケーラビリティ、および業界全体での広範なサポートにより、VoIPおよびマルチメディア通信の人気の選択肢となっています。

SIPメソッド

RFC 3261で定義されたコアSIPメソッドには以下が含まれます：

1. INVITE: 新しいセッション（コール）を開始するか、既存のセッションを変更するために使用されます。INVITEメソッドは、提案されたセッションの詳細（メディアタイプ、コーデック、トランスポートプロトコルなど）を受信者に通知するために、セッション記述（通常はSDPを使用）を運びます。
2. ACK: INVITEリクエストに対する最終応答の受信を確認するために送信されます。ACKメソッドは、エンドツーエンドの確認を提供することにより、INVITEトランザクションの信頼性を確保します。
3. BYE: 確立されたセッション（コール）を終了するために使用されます。BYEメソッドは、通信を終了したいことを示すために、セッション内のいずれかの当事者によって送信されます。
4. CANCEL: セッションが確立される前に、保留中のINVITEリクエストをキャンセルするために送信されます。CANCELメソッドは、送信者が気が変わった場合や受信者からの応答がない場合に、INVITEトランザクションを中止することを可能にします。
5. OPTIONS: SIPサーバーまたはユーザーエージェントの機能を照会するために使用されます。OPTIONSメソッドは、セッションを実際に確立することなく、サポートされているメソッド、メディアタイプ、または他の拡張に関する情報を要求するために送信できます。
6. REGISTER: ユーザーエージェントがSIPレジストラサーバーに現在の位置を登録するために使用されます。REGISTERメソッドは、ユーザーのSIP URIと現在のIPアドレスとの間の最新のマッピングを維持するのに役立ち、コールルーティングと配信を可能にします。

これらのコアメソッドに加えて、他のRFCで定義されたいくつかのSIP拡張メソッドがあります：

1. SUBSCRIBE: RFC 6665で定義されており、SUBSCRIBEメソッドは特定のリソースの状態（ユーザーのプレゼンスやコールステータスなど）に関する通知を要求するために使用されます。
2. NOTIFY: RFC 6665でも定義されており、NOTIFYメソッドは、監視されているリソースの状態の変化についてサブスクライブされたユーザーエージェントに通知するためにサーバーによって送信されます。
3. REFER: RFC 3515で定義されており、REFERメソッドは、受信者に転送を実行するか、第三者を参照するように要求するために使用されます。これは通常、コール転送シナリオで使用されます。
4. MESSAGE: RFC 3428で定義されており、MESSAGEメソッドは、SIPユーザーエージェント間でインスタントメッセージを送信するために使用され、SIPフレームワーク内でのテキストベースの通信を可能にします。
5. UPDATE: RFC 3311で定義されており、UPDATEメソッドは、既存のダイアログの状態に影響を与えずにセッションを変更することを可能にします。これは、進行中のコール中にコーデックやメディアタイプなどのセッションパラメータを更新するのに便利です。
6. PUBLISH: RFC 3903で定義されており、PUBLISHメソッドは、ユーザーエージェントがイベント状態情報をサーバーに公開し、他の関心のある当事者が利用できるようにするために使用されます。

SIPレスポンスコード

• 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: リクエストされたリソースはネットワーク内のどこにも存在しません。

例

SIP INVITEの例

INVITE sip:jdoe@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: John Doe <sip:jdoe@example.com>
From: Jane Smith <sip:jsmith@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jsmith@pc33.example.com>
User-Agent: ExampleSIPClient/1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Content-Length: 142

v=0
o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com
s=-
c=IN IP4 pc33.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000te

SIP REGISTERの例

REGISTERメソッドは、Session Initiation Protocol（SIP）で、VoIP電話やソフトフォンなどのユーザーエージェント（UA）がSIPレジストラサーバーに自分の位置を登録するために使用されます。このプロセスにより、サーバーは登録されたユーザー宛ての着信SIPリクエストをどこにルーティングするかを知ることができます。レジストラサーバーは通常、SIPプロキシサーバーまたは専用の登録サーバーの一部です。

以下は、REGISTER認証プロセスに関与するSIPメッセージの詳細な例です。

1. UAからレジスタサーバーへの初期REGISTERリクエスト:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

この初期のREGISTERメッセージは、UA（アリス）からレジストラサーバーに送信されます。これには、希望する登録期間（Expires）、ユーザーのSIP URI（sip:alice@example.com）、およびユーザーの連絡先アドレス（sip:alice@192.168.1.100:5060）などの重要な情報が含まれています。

2. 401 Unauthorized レジストラサーバーからの応答:

cssCopy codeSIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
Content-Length: 0

レジストラサーバーは「401 Unauthorized」メッセージで応答し、これには「WWW-Authenticate」ヘッダーが含まれています。このヘッダーには、UAが自分自身を認証するために必要な情報、例えば認証レルム、ノンス、およびアルゴリズムが含まれています。

3. 認証情報を含むREGISTERリクエスト:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
Content-Length: 0

UAは別のREGISTERリクエストを送信します。このリクエストには、必要な資格情報（ユーザー名、レルム、ノンス、および提供された情報とユーザーのパスワードを使用して計算されたレスポンス値）を含む"Authorization"ヘッダーが含まれています。

これがAuthorizationレスポンスの計算方法です：

import hashlib

def calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop):
# 1. Calculate HA1 (concatenation of username, realm, and password)
ha1_input = f"{username}:{realm}:{password}"
ha1 = hashlib.md5(ha1_input.encode()).hexdigest()

# 2. Calculate HA2 (concatenation of method and uri)
ha2_input = f"{method}:{uri}"
ha2 = hashlib.md5(ha2_input.encode()).hexdigest()

# 3. Calculate the final response value (concatenation of h1, stuff and h2)
response_input = f"{ha1}:{nonce}:{nc}:{cnonce}:{qop}:{ha2}"
response = hashlib.md5(response_input.encode()).hexdigest()

return response

# Example usage
username = "alice"
password = "mysecretpassword"
realm = "example.com"
method = "REGISTER"
uri = "sip:example.com"
nonce = "abcdefghijk"
nc = "00000001"
cnonce = "lmnopqrst"
qop = "auth"

response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
print(f"MD5 response value: {response}")

4. 成功した登録 レスポンスはレジストラサーバーからのものです:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

レジストラサーバーが提供された認証情報を確認した後、登録が成功したことを示す「200 OK」レスポンスを送信します。レスポンスには、登録された連絡先情報と登録の有効期限が含まれています。この時点で、ユーザーエージェント（アリス）はSIPレジストラサーバーに正常に登録され、アリスへの着信SIPリクエストは適切な連絡先アドレスにルーティングされることができます。

コールの例