はじめに
前回はSIPにおける、SIPサーバを使用しないセッション確立の手順を紹介しました。つまり、SIPサーバを使わない＝相手のIPアドレスを事前に知っている場合ということです。しかし、大抵の場合は相手のIPアドレスまでは知らないということなので、今回はSIPサーバを使って相手のIPアドレスを知らなくてもセッションが確立できる！ということを具体的なシーケンスと共に紹介していきます。
【９秒チャレンジ】
1. REGISTER：各ユーザーが自分のSIP URIとIPアドレスをSIPサーバーに登録。
2. INVITE（発→SIP→着）：通話をかける側が相手のSIP URIをSIPサーバーに送信。
3. 100 Trying（SIP→発）：SIPサーバーが呼び出しを転送中であることを通知。
4. 180 Ringing（着→SIP→発）：受け手側が呼び出し中であることを通知。
5. 200 OK（着→SIP→発）：受け手側が通話を受け入れたことを通知。
6. ACK（発→着）：通話セッションの確立を確認。
7. RTP通信：音声・映像のデータ交換が開始される。
8. BYE→200 OK：通話終了の通知。
更に詳しく知りたい場合↓
SIPセッション確立の基本的な流れ
SIP（Session Initiation Protocol）は、VoIP（Voice over IP）やビデオ通話などのリアルタイム通信で広く利用されている通信プロトコルです。SIPを使用した通話のセッション確立は、以下のようなシーケンスで行われます。相手のIPアドレスを最初に知らない場合、SIPサーバーが中心となってIPアドレスを解決し、最終的には直接通信を開始します。
1. ユーザーエージェントの登録（REGISTER）
最初に、通話をかける側（発呼側）と受ける側（着呼側）は、事前にSIPサーバーに自分の情報（IPアドレス、利用者識別子など）を登録する必要があります。これをREGISTERリクエストと言います。
- 登録内容: 各ユーザーエージェント（UA）が自分のSIP URI（例:
sip:hako@example.com）とそのIPアドレスをSIPサーバーに送信します。これにより、SIPサーバーは各ユーザーのSIP URIとそのIPアドレスを関連付けて記録します。 - 目的: SIPサーバーは、他のユーザーから来た呼び出し要求に対して、どのIPアドレスに転送すればよいかを知るために、ユーザーのSIP URIとIPアドレスのマッピングを保持します。
これにより、相手のIPアドレスが不明でも、SIPサーバーを介して呼び出しができるようになります。
2. INVITEリクエスト（発呼→SIPサーバ→着呼）
通話をかけたい側は、SIPサーバーにINVITEリクエストを送信します。このリクエストには、通話相手のSIP URIが含まれています。
- 役割: 発呼側は、相手のIPアドレスを知らないため、SIPサーバーを通じて呼び出しを行います。
- SIPサーバーは、受信したSIP URIに対応するIPアドレスを探し、呼び出し先に転送するための処理を行います。
SIPサーバは相手（着呼側）のSIP URIからIPアドレスを割り出し、そこへ転送する。
3. 100 Trying（SIPサーバ→発呼）
SIPサーバーは、呼び出し要求を処理中であることを示すために、発呼側に「100 Trying」というレスポンスを返します。
- 役割: これは、SIPサーバーが相手のIPアドレスを探していること、つまり転送中であることを発呼側に伝えるための応答です。
4. 180 Ringing（着呼→SIPサーバ→発呼）
次に、着呼側が通話の準備が整った時、着呼側のユーザーエージェントは、SIPサーバーに「180 Ringing」というレスポンスを送ります。
- 役割: 「180 Ringing」は、呼び出し中であることを示し、受け手側が電話を鳴らしている（または受け入れる準備ができている）ことを発呼側に知らせます。このレスポンスは、通話が始まる前に発呼側に伝えられます。
発呼側に「トゥルルルー」という呼び出し音が聞こえたらそれは、180 Ringingが届いたサインです。まぁ要するに、ちゃんと届いているよーという合図です。
5. 200 OK（着呼→SIPサーバ→発呼）
着呼側が電話を受けた後、着呼側は通話を開始する準備が整ったことを示すため、「200 OK」というメッセージをSIPサーバーに送信します。
- 役割: これにより、通話が実際に確立される準備が整ったことを発呼側に伝えます。このメッセージには、通話に関するセッションの詳細（例えば、使用するメディアの形式など）が含まれています。
- 重要なポイント: この時点で、SIPサーバーは相手のIPアドレスと関連情報を持っており、発呼側とチャッコ側は通話を開始する準備が整います。
200 OKにより、着呼側のIPアドレスが発呼側に伝わります。
6. ACK（確認応答）
発呼側は、「200 OK」メッセージに対して、「ACK」という確認応答を返します。
- 役割: これにより、通話セッションが確立されたことが確認されます。双方のユーザーエージェントが直接通信を行う準備が整い、SIPサーバーを介さず、ハッコ側とチャッコ側は直接通信を開始します。
このACKは既に着呼側のIPアドレスが分かった状態なので、SIPサーバを介さず直接着呼側に送ります。
7. RTP通信（音声・映像の交換）
通話が確立されると、実際の音声や映像のデータ交換は、**RTP（リアルタイムトランスポートプロトコル）**を使って行われます。
- 役割: RTPは、SIPのような制御プロトコルと異なり、実際のデータ（音声や映像）をリアルタイムで送受信するためのプロトコルです。ここで、ハッコ側とチャッコ側は直接、RTPを使ってデータを交換します。
- SIPサーバーの役割: 通話が確立された後、SIPサーバーは役割を終え、データ交換は直接行われます。
8. BYE（セッション終了）
通話が終了した時、いずれかの側（発呼または着呼）が、「BYE」メッセージを送信します。このメッセージはセッションを終了するためのリクエストです。
- 役割: 通話が終了したことを伝え、双方にセッションの終了を知らせます。受け取った側は、「200 OK」で応答し、セッションが終了します。
まとめ
- レジスタリクエスト（REGISTER）：各ユーザーが自分のSIP URIとIPアドレスをSIPサーバーに登録。
- インバイトリクエスト（INVITE）：通話をかける側が相手のSIP URIをSIPサーバーに送信。
- 100 Trying：SIPサーバーが呼び出しを転送中であることを通知。
- 180 Ringing：受け手側が呼び出し中であることを通知。
- 200 OK：受け手側が通話を受け入れたことを通知。
- ACK：通話セッションの確立を確認。
- RTP通信：音声・映像のデータ交換が開始される。
- BYE：通話終了の通知。
このように、SIPサーバーは相手のIPアドレスを知らない場合に通話のルーティングを行い、最終的に直接通信へと移行します。通話中のデータはRTPを使用して直接やり取りされるため、SIPサーバーは通話の管理（開始・終了）にのみ関与します。
