はじめに
普段私たちが使っている音声・ビデオ通話にはVoice over IP (VoIP) の技術が使われています。このVoIPなのですが、その技術や設計の中身が非常にわかりにくい！そのため本記事では、VoIPの設計や使用されているプロトコル、標準化について解説を行いたいと思います！
ネットワーク技術は標準化に向かう
まず、VoIPの解説を行う前にNW技術・設計の標準化について触れたいと思います。標準化はNWのスケーリングやサービス品質の保証にとってとても重要です。例えば通信事業社Aと通信事業社BのNW間で通話をするときのことを考えてみます。
この時A社IMSにおける通話のプロトコル（コーデックやSIPシーケンス、フォールバック等）とB社におけるプロトコルで整合性がとれていなければ、正常な通話を行えません。まるで、各通信事業者が各々の言語や方言で通話を始めようとする状態になります。そのため、各事業者の通話のプロトコルを合わせ、互いに共通のメッセージやフローを用いて通話の制御を行う必要があります。このときの共通の取り決めを決めるのが標準化です。
そして、標準化した規格の取り決めを記した文章が標準化文書です。世界的に有名なものといえばIETFが発行するRFCですね！ほかにも、3GPPやITU-Tの発行する勧告があったり、日本ではTTCが発行するJJ9030などの文書があります。
VoIP誕生
昔の電話で使われる回線はアナログ回線＋IP網でないデジタル回線でした。アナログ回線は音声信号をそのまま電圧に変換して電線に乗せるような方式であり、デジタル回線はCircuit Switchingと呼ばれる方式を用いています。これらの組み合わせで通話のNW網が成り立っていたようです。しかし、この方式はデータ送受信の効率が悪いことや音声専用のインフラを整備する必要があるなどのデメリットが存在します。
そのため、これらの欠点を解消できるIPネットワークの普及が進むにつれ、IP網を使って通話をするような技術の開発が進みました。それがVoIPなわけです。IP網は音声専用のNWではなく様々なデータを運ぶことができます。また、パケット交換方式なのでデータ転送の効率も良いです。このようにVoIPは従来の電話回線のデメリットを解消しているわけですね！
VoIPでは、制御信号にIPネットワーク上で動くSIP、音声信号にIPネットワーク上で動くRTPというプロトコルを用います。どちらのプロトコルもRFCによって標準化されています。
ここまでで、VoIP技術ではSIPやRTPというプロトコルが用いられていることがわかりました。しかし、実際これらのプロトコルが何なのかはまだよくわかりません、、、
そのため以下からはこれらのプロトコルについてより理解を深めていきましょう！
SIP
Session Initiation Protocol (SIP)は、メディアセッション（通話、ビデオ通話など）を開始、変更、終了する際に用いる制御信号のプロトコルです。具体的には、相手のIP電話機への呼び出しを行ったり、通話を切ったりするために送る信号を規定します。
INVITE
通話を開始するためにはINVITEメッセージ、通話を切るときにはBYEメッセージを送信します。また、INVITEを送信してからBYEで通信が終了するまでの期間のことをダイアログといいます。以下が最も単純なダイアログ中のSIPメッセージです。
実際に通話する部分のプロトコルはRTPを用いますが、そのほかの通話開始や終了を制御する部分がSIPとなります。
この例では、通話を開始する側（発信側）と通話に応答する側（着信側）が直接通信を行っていますが、実際には2者の間にプロキシが入る場合もあります。以下ではその例を見てみましょう。
INVITE（Proxy仲介）
プロキシが仲介するとは、いわば受付係が存在するようなものです。
このように、プロキシは、Aさんの「Bさんを呼んで」リクエストを仲介して実際にBさんを呼びに行ってくれます。このメリットは何でしょうか？もしもプロキシが存在しない場合、AさんはBさんがどこにいるかの位置情報を確認して直接呼びに行かなければいけません。しかし、Bさんは日によっている場所が変わるかもしれず、直接呼びに行くのは大変です。そこで受付係となるプロキシがBさんの位置情報を常に把握し続けることで、Aさんからのリクエストの窓口を統一しつつ、Aさん目線でどこにいるかわからないBさんの呼び出しをいつでもできるようにしているわけです。
さて、通信の世界の言葉に戻します。まずAさんの「Bさんを呼んで」リクエストはINVITEに相当します。このとき、AさんはBさんの位置情報=IPアドレス（or IPアドレスと直接紐づいているドメイン名）を知りません。そこで、プロキシに向けて「Bさん」という恒久的な名前に相当するAoR（Address of Record）による呼び出しを行います。例えば以下のような形です。
INVITE sip:B@example.com SIP/2.0
この、B@example.comが「Bさん」という名前に相当するAoRです。このINVITEを受け取ったプロキシは、「ちょっと待ってて」に相当する暫定応答 100 TryingをAさんに返送します。その後、プロキシ内でBさんのIPアドレスを検索し、そこに向けてINVITEを送信します。以下にダイアログのフローを示します。
proxyは相手が通話に出た時点で役割終了です。ここまでのフローでAさんとBさんが互いのIPアドレスを知ることができるため、仲介が必要なくなるためです。ここまでで、proxyが仲介したダイアログのフローとproxyの仲介理由について理解できました！
REGISTER
さて、ここで一つ疑問が生じます。それは「受付係であるproxyはどうやってBさんのsip端末のIPアドレスを知るのか」ということです。ここで用いられるのがREGISTERリクエストです。REGISTERでは、Bさんのsip端末側が定期的に自身のアドレス（これをContactアドレスといいます）をプロキシに送ることで、位置情報を伝えています。REGISTERが必要になる場合は、例えば以下のような場合です。
Bさんがwifi→5G網へ移動した場合、sip端末のIPアドレスは変化します（これに伴い、IPアドレスと直接結びついているドメイン名も変化するでしょう）。このような場合に、Bさんはproxyに今の正しいアドレスを伝えなければ、INVITEを受け取ることができません。そのため、REGISTERリクエストを用いて定期的に位置情報を更新させることにより、正しいアドレスでINVITEを受け取れるようにします。REGISTERリクエストの例を以下に示します。
REGISTER sip:example.com SIP/2.0
Max-Forwards: 70
To: Bob <sip:B@example.com>
From: Bob <sip:B@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:B@wifi.example.com>
Expires: 7200
Content-Length: 0
今回は1,3,7行目のみに注目します。
まず、3行目のToヘッダにはAoRを設定し、このREGISTERが「Bさん」からのものであることを示します。次に、7行目のContactヘッダには、「Bさんが実際にいるアドレス」であるContactアドレスを設定します。最後に、1行目はRequest-URI部と呼ばれ、Proxyが持つ位置情報を正しく管理するサービスのドメインを設定します。このサービスのことをLocation Serviceといいます。もう少し簡単に言うと、「AoRをContactアドレスに変換してくれるサービスを提供するサーバ」のドメインを設定します。
Registerとlocation Serviceの関係は以下のようになります。
上の図では、SIP ServerとLocation Serviceを別々に記載していますが、実際には1つのサーバにSIP Server（Proxy機能）とLocation Serviceを内包していることも多いです。
以上がSIPの基本的な機能となります。最後に通話開始までの流れを整理すると以下のようになります。
- Bさんのsip端末はREGISTERリクエストで、自身の位置情報をSIPサーバのlocation serviceに登録する
- Aさんのsip端末がBさんへ通話をかける際は、INVITEリクエストをSIPサーバに送信する
- SIPサーバのlocation serviceにより、INVITE内のAoRからContactアドレスを得る。SIPサーバはBさんのContactアドレスに向けてINVITEを送信する
- ダイアログのメッセージフローに従い、メディアセッションが始まる
RTP
Real-time Transport Protocol (RTP)は、音声やビデオなどのメディアデータをリアルタイムで送信するためのプロトコルです。SIPによって、ダイアログ上で通話が開始できる状況になるとRTPの送受信が始まります。RTPの詳細は割愛しますが、とりあえず音声データをRTPで送っているということ、UDP上で送っていることだけ理解していれば今のところ大丈夫なはずです（多分）。
IMS
ここまでで、メディア通信で使われるプロトコルとそのフローの解説を行いました。ここからは、メディアサービスのためのネットワークアーキテクチャIP Multimedia Subsystem (IMS) について解説を行います。
IMSとは簡単に言うと、通信事業者が通話やその他のメディアサービスを提供するためのIPネットワーク基盤・アーキテクチャ構成のことです。ただのVoIPサービスを提供するだけでなく、課金や認証、QoSの制御など、通信事業者特有の様々な機能を備えたアーキテクチャです。IMSの主な構成要素には以下のものがあります。
CSCF
Call Session Control Function (CSCF)はIMSで中心となるSIPサーバの機能です。UEとの接点となるP-CSCF、外部NWとの接点となるI-CSCF、SIPの中核的な機能を担うS-CSCFがあるようです（が、実際どんな感じかはわかりません）。
HSS
Home Subscriber Server (HSS)はIMSサービスを利用する契約をしている加入者の情報を管理するDBです。HSSでは、ユーザが利用できるサービスやNW要素の割り当てを管理しています。
AS
Application Server (AS)では留守番電話やIVRなどのVoIPサービスを提供します。S-CSCFが適切にASへのルーティングを行うことで、付加サービスが提供されます。
SIP
制御信号のプロトコルとしてSIPが用いられます。
今のところの理解と想像でIMSを図解する
IMSの構成要素はその役割や責任分担によって細分化されています。簡単に図にすると以下のようになります（という理解です、現時点で）。
各CSCFは、以下の点で責任を持っています。
・P-CSCF：UE側NWとIMSのセキュリティ境界、この区間のQoSを管理する
・S-CSCF：VoIPサービス、ASと連携したVoIP付加サービスを提供する
・I-CSCF：外部NWからのSIPリクエストを受け、VoIPサービスが提供できるように適切なS-CSCFにルーティングする
以下から、REGISTER、IMS内でのダイアログ確立、外部NWからのコール受信、IVRの利用の4つの例を用いて各構成要素の役割を理解していきます。
REGISTER
UEが初めにIMSと接続する際、P-CSCF Discoveryにより、P-CSCFとの接続情報を入手します。これによりIMSと接続できるようになるとS-CSCFへREGISTERを送信することにより、UEのContactアドレスがS-CSCF内のLocation Serviceに登録されます。この際、UEには対応するS-CSCFが割り当てられ、その情報がHSSに登録/更新されます。また、P-CSCFにもユーザとS-CSCFの対応関係が記録されます。このように位置情報やルーティング情報が登録されることで、VoIPサービスを正常に受ける準備が整います。
IMS内でのダイアログ確立
IMS内でのダイアログ確立はUE→P-CSCF→S-CSCF（→S-CSCF）→P-CSCF→UEの経路をたどります（と思われます）。前述したINVITEのフローやそこからさまざまな認証・拡張を加えたフローに沿ってダイアログが確立されます。
外部NWからのコール受信
外部NWからのコールはIBCF（詳細は次回以降に解説）を通過し、I-CSCFで適切なS-CSCFへルーティングされます。この時、I-CSCFはHSSに登録された加入者とその担当S-CSCFの情報を検索することにより、適切なルーティングを行います。外部NWからのコールが適切なS-CSCFまで届けられると、後はP-CSCFをプロキシして正しいContactアドレスを持つUEまでルーティングされます。
IVRの利用
ユーザがIVR（自動音声応答）を利用する場合、UEからのリクエストはS-CSCFによりAS側に転送されます。これにより、ASとのセッションを確立することで、VoIP付加サービスを利用することができます。
IMSの構成要素はまだ存在しますが、いったん雰囲気を掴めたのではないかと思います。
終わりに
ここまでで、メディアネットワークの基礎的な要素について解説しました。次のパートからは、IMS-IMS間でVoIPサービスを提供するためのInter-IMSの概念と、Inter-IMSを可能にするためのプロトコルの詳細部について見ていこうと思います。