設問１
（２）131,072
１つのIPアドレスで使えるポートは2^16(65,536)個。
問題文中に２つのIPアドレスを使用すると書かれているので、A.65,536×２＝131,072
＊ポート番号は16ビットで表現される。なので、2^16
（３）①許可する通信を追加する/②宛先NATに関する定義を追加する
①許可する通信を追加する：Webサーバが増えるということはそこに到達させるためのIPアドレスが必要になる。そしてそれをクライアントが接続要求した際に届かせる必要がある。なので、それを許可リストに入れる必要がある
＊ACLの場合、許可しないと暗黙のdenyによって拒否されてしまうので明示的に追加する必要がある。
②宛先NATに関する定義を追加する：p.4の5行目でIPアドレスの組み合わせは１対１に固定とある。なので、Webサーバが追加されたら、そのプライベートIPアドレスをグローバルIPアドレスに対応づける必要があるのでNATの定義を追加する必要がある。
設問２
（２）応答が行きの宛先IPアドレスとは異なる送信元IPアドレスから戻る
なぜ、これが問題なのか…？ →クライアント側でステートフルインスペクションを設定していると、意図した送信元からではない通信が来ることになるので、そのパケットは拒否されることになる。
設問３
（３）vlan1,vlan2
この回答はつまり、STUNサーバ１，２がL2SW1とL2SW2にそれぞれ接続することを意味している。
Q.FWよりも外にSTUNサーバを配置しちゃったら外部ユーザにも利用され放題じゃない？危険じゃない？
A.L2SWのACLやSTUNサーバ自体のホストFWで防御が可能。また、STUNサーバには内部情報が入っているわけではないので外部から利用されても特にセキュリティ上問題ない。
＊L2SWというとIPアドレスやポートが見れないイメージだがACLなどの適用は可能
設問４
（１）カ：HTTP キ：WebSocket
カについては、問題文中にWebRTCを使う旨の記載がある。つまり、接続の開始はHTTPであると判断できる。キのWebSocketについては図6中にUpgrade:websocketとあるようにSIPでは自発的な双方向通信が求められるため、WebSocketが該当する。また、問題文中のキの後に「切り替え」という文字から、HTTPから切り替えできるのはWebSocketだ！という発想になる。
Q.HTTPが使われる理由…
A.問題文中にはブラウザを使って音声のやり取りをする旨の記載がある。スマホ用のアプリケーションであれば独自のさまざまなプロトコルが使える。しかし、ブラウザでは基本的にHTTPが主流。なので、ブラウザをつかって何かをしたいなら、まずはHTTPベースで考えましょうね！ということ。
そして今回の話にすり合わせると、WebRTCを使う旨の記述がある。WebRTCという「専用のアプリ/プラグインを必要としない仕組み」上、ブラウザのHTTPで始める必要があるというわけです。
Q.WebSocketってそもそもなに？…
A.HTTPの拡張機能。従来のリクエスト/レスポンス方式から双方向通信が可能となるように拡張された。そのためSIPなどにおいて、もし、リクエスト/レスポンス方式のままだとクライアントはサーバに対して「僕に対する着信ある？」を定期的に聞きに行く必要がある。これは端末のバッテリー、通信料、サーバ負荷などいろいろとデメリットがある。しかしWebSocketであれば、着信があればサーバ側から呼び出しが可能であるため必要な時に必要な分だけ自由に通信できるようになる。
Q.WebSocketが使われる理由…
A.HTTPはリクエスト/レスポンス方式。つまり、サーバ側から自発的にデータを送ることができない。しかしSIPにおいては、両者とも自発的に通信を開始できるようにしたい。かつ、それらの動作を、ブラウザ（HTTP）上で実行したい。この２つの条件を満たせるのがWebSocket。だからWebSocketが使われる。
Q.なんで最初からWebSocketじゃないのか…
A.WebSocektはHTTPの拡張。そのため、まずHTTPで通信を整えてからじゃないと使えない。最初からWebSocketでやるのは仕様上、不可能。
Q.なんでアプリケーション層のプロトコルをアプリケーション層のプロトコルでカプセル化しているの？…
A.SIPはアプリケーション層プロトコル。WebSocketもアプリケーション層のプロトコル。そのままSIP送っちゃだめの？という疑問がある。通常は[IP] [TCP/UDP] [SIP]のような構成で十分。しかしWebRTCだと[IP] [TCP] [WebSocket] [SIP]になっている。そこにはブラウザのルールがある。ブラウザはブラウザ自身が認めたプロトコル（HTTP、WebSocket）以外は基本的にそのまま送信しちゃいけない。なのでSIP通信は許可されたWebプログラム（JavaScript）ではないのでWebSocketに包んでいる。
Q.ブラウザが許可されていないプロトコルをHTTPやWebSocketで包むメリット…
A.通信をブラウザ管理下にすることができる。
Q.なんでRTPはWebSocketでカプセル化しないの？…
A.RTPに関してはブラウザが自分で作ったデータだからWebSocketなどで包む必要がない。Webプログラム（JavaScript）などはサーバ側によって挙動が決まってしまう。そのため安全性をもとめてHTTPやWebSocketで包む。しかしRTPの場合はブラウザ側に主導権があり、ブラウザがパケットを作成するため信頼性があるためわざわざ包まなくてもよい。
また、RTPは即時性を求めるUDPであるためHTTPやWebSocketのようなTCPだとオーバーヘッド等の点を考慮すると包むべきではない。
（２）ISP１とISP2から払い出されたIPアドレスを一つずつ割り当てる。
2つの異なるISPから払い出されたIPアドレスを割り当てないと意味ないよねと。そうしないと、もしも同一のISPから払い出されたIPアドレスを登録していたら、そのISP、1つが落ちたらIP－PBX自体が機能しなくなってしまう。なので、異なるISPから払い出されたIPアドレスを自社DNSのAレコードに登録して、そうすることによって名前解決で2つの異なるISPからのIPアドレスをクライアントに返すことができる。そうなれば1つのISPが落ちたとしても、もう一方の方のISPでのアドレス空間は生きているので、そっちでカバーが可能だよねっていうこと。
（３）vlan１,vlan2
IP-PBXはインターネットからのパケットをFWを通す前の段階で受け取りたいから。そして、マルチホーミングをするという観点で、２つのISPを利用できるようにL2SW1（vlan1）とL2SW2(vlan2)に接続する必要がある。
Q.IP-PBXをFWの内側に配置しなくてもいいの？
A.注目すべきはp.9に記載されている”IP-PBXはSessionBorderControllerとして動作し、グローバルIPアドレスとプライベートIPアドレスを変換する”という箇所。そもそもSBCは、一般的なWebサーバとは異なり、音声通信に特化したサーバである。また、セキュリティ的にもSBCには強固な音声専用FWが搭載されていることが多い。そのためFWの内側に配置しなくてもセキュリティ的には問題ない（むしろ配置すべきでない）。
Q.IP-PBXをFWの内側に配置すればよくね？
A.一見すると、FWの内側に配置すればSBCの強固なセキュリティとFWのフィルタリングによって二重のセキュリティを享受できると感じる。しかし、実際はFWの外側でなくてはならない理由がある。
理由：音声通話に使うRTPは動的にランダムなポートを使用する。基本的にFWは事前定義されたルールに従ってフィルタリングする。しかし、動的ランダムポートだと制御ができず誤ってブロックしてしまうことがあるため。そのためFWよりも外側に配置する必要がある。
図３を見ると、IP-PBXはL3SW1に直接ぶっ刺さってバイパスされているので構成的にFWを通らなくてもよいという美しい構成になっている。
Q.SBCのB2BUAのセキュリティ担保について…
A.B2BUAは外側と内側のセッションを完全に分断する。つまり、FWやルータのように外部からのパケットをそのままバイパスするわけではなく、仲介役（ここではIP-PBX）が新たにパケットを０から作りなおして内側に送りだす。そのため、外部からきた悪意のあるパケットも、仲介役が内側へのパケット構築中に「ん？これおかしいぞ」と、きづくことができ、遮断できる。
似ている概念としてはSSLインスペクション。これも外と内のセッションを完全に分断することで仲介役が主導権を握り、パケットの検査等がしやすくなるというもの。
（４）ク：IP-PBX ケ：DNS コ：LB
通信の手順と照らし合わせることで納得できる。
以下の手順３，４，５より問題文中の空欄の回答はク：IP-PBX ケ：DNS コ：LBになる。
１．クライアントがWebブラウザでAPサイトにアクセス
２．URLから名前解決をしてA社のWebサーバからプログラム（JavaScript）をダウンロードする
３．２のプログラム内に「IP-PBXはこのFQDNですよ。接続してくださいね！」という命令があるのでそれに従う。
４．３の命令に従いAPはIP-PBXのFQDNの名前解決をするためDNSクエリを発行する
５．IP-PBXの権威DNSはA社のロードバランサー（LB）になるので、最終的にそこからIP-PBXのAレコードを取得する
６．そのAレコードに従ってIP-PBXに対してHTTPでセッションを確立し、WebSocketに切り替える
＊ブラウザを使っているので直接SIP接続ではなくHTTPを挟む必要がある。また、WebSocketに切り替えることで自発的な双方向通信ができるようになる。その結果、発信だけでなくサーバからの着信にも対応できるようになる。
設問５
（１）サ：切り戻し
切り戻し：システムの切り替えを試みたけど、正常にいかなかったから元の状態に戻すこと。
（２）FQDNの数：１ グローバルIPアドレスの数：４
マルチホーミングを実施していてもFQDNは１つで十分。そのFQDNに対するＡレコードを冗長化していればマルチホーミングを構成できる。逆に増やしてしまうとDNSサーバ管理などが複雑になってしまう。そのためFQDNは１つでよい。
グローバルアドレスについては、ISP１とISP２から割り当てられているIPアドレスをそれぞれ１つずつ割り当てることでマルチホーミングが可能。また、問題文中のp.4の3~5行目に”変換前のIPアドレスの組み合わせは１対１に固定”とある。これはもし、シングルホーム（１つのISP）で、2台のWebサーバで運用していたとしても、１つのWebサーバに１つずつのグローバルIPアドレスが必要ということになる。そして、今回のケースは２つのISPを使っているので、必然的に１つのWebサーバにはISP１のIPアドレスとISP2のIPアドレスが必要になり、それが２台の構成なので「２つのIP×２台のWebサーバ＝４」ということになる。
別ケース①：もし、３つのISPを使って、２台のWebサーバ構成なら、１つのWebサーバに３つのIPを割り当てる必要があるので「３つのIP×２台のWebサーバ＝６」。このようなIPアドレス構成になる。
別ケース②：もし、１対１のstatic方式ではなく宛先NAT方式（DNAT）ならどうなるか。。。答えは「２つのグローバルIP」で構成可能。２つのISPから払い出されたIPアドレスをLBの仮想IPとして、DNSに登録しておく。そうすれば、あとは内部で勝手にWebサーバ１、２に分散される。１つのISPが落ちても残りのISPからのアドレスでWebサーバ１，２への分散通信は継続される。
（３）IP-PBX,STUNサーバ１,STUNサーバ２
IP-PBXについては、設問４（４）にもある通り、WebSocketでSIPをやり取りする必要があるので事前にIP-PBXの名前解決が必要となる。
STUNサーバ１とSTUNサーバ２についてはSIPセッションで自分の外部用のIPアドレスを知っておく必要があるため名前解決が必要になる。
Q.STUNサーバが２つある意味は？
A.マルチホームしているため、内部ユーザは結果的に２つのIPアドレス空間を使えるようになる。そのためSIPに指定する自分のIPアドレスの候補として２つのIPアドレスを準備しておく必要がある。
もし、１つのSTUNサーバしか利用しないと１つのISPからのアドレス空間しか返せない。。その結果、１つのISPで障害が起きるとSIPセッション自体も成立させることができなくなってしまう。
（４）FW
2通りの定義ファイルとは変更前と変更後のファイルをあらわしている。つまり、変更前後の両方に存在する機器だなぁと推測を立てる。その中で、主に設定変更が必要な機器は何か。。と考えるとFWが浮かび上がる。変更前のFWはDNS機能、NAT機能等を実装していた。しかし変更後はLBに引き継いでいる。そのように変更前後で設定する内容が違うのはFWなので答えもFWになる。
（５）①社外からWebサーバへのアクセス / ②社内からWebサーバへのアクセス / ③社内からインターネットへのアクセス
①社外からWebサーバへのアクセス：社外→Webサーバへの経路途中に新規LBが追加されたので、その新規LBの動（DNS機能やNAT機能等）作、並びに変更後のFW設定（フィルタリングの改修等）が正常に設定されていることを確認する
②社内からWebサーバへのアクセス：社内→Webサーバへの通信においては、こちらもFW（フィルタリング）やLB（WebサーバへのDNS機能等）を利用するため正常に動作することを確認する
③社内からインターネットへのアクセス：こちらもFW,LBを経由するため正常な動作を確認する必要がある。
まぁそもそもA社においては上記３つの通信しか基本的に発生しない。なので、「配置変換や設定変更を実施したから特定の経路を検査しよう！」というよりも、そもそも３つしか存在しないので難しく考え過ぎずわからないかったら思い浮かぶ通信の種類を記述するというのも一つの手。
（６）ISP２を経由した外向きDNS機能を確認する
問題文中の下線(n)には”ドメイン登録事業者に~~”と記されているためDNS関係の処理であることが推測できる。さのため、マルチホーミングに必要なDNS関係の処理を頭に浮かべることで答えが導き出される。では、具体的にどうのようなDNS設定が必要かを見ていこう。
１．マルチホーミングをするためにはA社のDNSサーバ（LB）自体のIPアドレスにISP１とISP２のIPアドレスを割り当てる必要がある。
２．また、そのA社DNSサーバまでたどり着くには上位DNSサーバがA社DNSサーバのホスト名とIPアドレスを把握しておく必要がある。
３．上位DNSサーバは自動でA社が追加したISP2のIPアドレスを反映させることはできない。
４．そのため、A社側が上位DNSサーバに対して、「僕はこのFQDNの権威DNSサーバです。で、IPアドレスはこれとこれです！」と上位に登録して教えてあげる。
５．そうすると上位DNSサーバがA社のドメインに対する名前解決を受けると、「A社ドメインの権威DNSサーバはこのFQDNで（NSレコードで提示）、IPアドレスはこの２つですよ（グルーレコードで提示）」と教えてくれる
６．クライアントは２つのAレコードから接続可能なIPアドレスへ接続する。
上記手順により、もしISP１に障害が発生したとしても、ISP２のDNSで名前解決できるためサービスの継続利用、つまりマルチホーミングの旨味を享受できるようになる。
おっと、話を元に戻すと、今回確認したいことは、上記手順４と５のテスト。つまり、ISP２側のDNS設定が正しく設定されており、そのルート使ってアクセスできるかを確かめる。それを簡単に表現すると回答のように”ISP2を経由した外向きDNS機能を確認する”となる。
（７）①’、③、④
①：ブラウザ１（外部）からSTUNへはFWを経由しないため特に追加設定は不要。そのため回答から除外
①’：STUNサーバは切り替え２によって追加された機器。そしてブラウザ２（内部）から新設されたSTUNに行くにはFWを経由する必要がある。つまりFWの設定を変更する必要があるので回答に記載
②：Webサーバを使った通信。これは既存環境と同じなので特に追加設定は不要。そのため回答から除外
③：社内から外についてのUDPポートを許可する設定が必要。WebRTCではP2P通信をしたいので固定されたポートではなく、その都度ユーザ間で動的にポートが決定される。そのため、その動的なポートを許可する設定を追加する必要がある。
④：③と同様の理由。動的ポートを許可する設定を追加する必要がある。
以上より「切り替え２で許可する通信」は①’,③,④となる。
p.3 マルチホーミング
Q.マルチホーミングを有効にするための前準備…
A.外部との接続点を増やせば勝手に冗長化できるわけではない。DNS設定の変更や各サービスに複数のIPアドレスを割り当てたりしたりといろいろとやることがある。
落とし穴１：例えば、自社のDNSサーバのAレコードにhttps://example.comに対するIPアドレスを異なるISPから割り当てられたIPアドレスを登録しただけではマルチホームにならない。
しっかりと自社DNSサーバ自体にも複数のIPアドレスを割り当てなければならない。なぜなら既存契約のISPに障害があればそもそもDNSサーバに名前解決要求が届かずhttps://example.comに設定した２つのAレコードが提供できないから。
落とし穴２：また、自社DNSサーバ自体に複数のAレコードを追加するだけでもマルチホームにはならない。その自社DNSサーバの上位DNSサーバの、グルーレコードとして、既存のDNSサーバIPだけでなく新規ISPから割り当てられたIPアドレスも登録しておく必要がある。これにより、マルチホームできるようになる。
Q.DNSの流れ https://example.comの名前解決の流れ
１．クライアントが当該サイトhttps://example.com/test.phpを開こうとする
２．まずは「.（ルート）」に、「example.com」を管理しているDNSサーバのFQDNを聞く
３．ルートが.comを管理しているDNSサーバのFQDN（NSレコード）とグルーレコード（≒Aレコード）をくれる
４．３のAレコードのIPアドレスをもとに.com権威DNSサーバに「example.com.」のを管理しているDNSサーバのFQDNを聞きに行く
５．com.権威DNSサーバがexmaple.com.の権威DNSサーバのFQDN（NSレコード）とIPアドレス（グル－レコード）を返してくれる
６．example.com.の権威DNSサーバが分かったので、そのDNSサーバにexample.com.のIPアドレス＝サービスを提供しているWebサーバのIPアドレスを教えてくださいと要求
７．example.com.権威DNSサーバがexample.com.のAレコードを教えてくれる
８．クライアントは7をもとに、Webサーバへアクセスする
p.3 表１ ip1/29
このアドレス空間で使えるIPアドレスの個数は32-29=3 2^3=8 ネットワークアドレスとブロードキャストアドレスの２つを引くと8-2＝６ つまり6個のアドレスが使えることになる
p.4 NAT
NATには複数の種類がある。
１．SNAT(Source NAT):送信元を書き換える。主に内から外の通信に使われる。
２．DNAT(Destination NAT):宛先を書き換える。主に外から内の通信に使われる。
３．静的NAT(Static NAT):変換前IPと変換後IPを１対１の固定する。これにより外から内への通信もスムーズにさせる。
５．動的NAT(Dynamic NAT):プールされたIPアドレスから、その都度割り当てる。。そのため外から内へ始まる通信には不向き。
p.4 FWのDNSラウンドロビン機能
Webサービスのドメインに対応するIPアドレスを負荷分散対象先となるWebサーバの複数IPアドレスに対応づけた複数のAレコードを準備する。それをDNS要求のたびに順番に返していくことで負荷が分散される
p.4 負荷分散装置（以下、LBという）があり、この装置は負荷分散機能のほかにDNS機能～
LBのDNS機能：LBが死活監視をして死んでいる回線があれば、それに付随するDNSレコードを返さないようにするといった動的な制御が可能になる
p.5 STUN
自分が外部と通信しているときに、NATで変換された後の送信元IPアドレス＆送信元ポート番号を知ることができる
*不随としてステートフルインスペクション、ホールパンチング、フルコーンNTA、TURNも頻出する
*ステートフルインスペクション：自分→外への通信の戻りパケットしか受け取らない仕組み。つまり、外から始まる通信は拒否される。なお、ステートフルインスペクションには２つの手法（フルコーンNATと制限型コーンNAT）がある。
*フルコーンNAT：一言でいうと制限がガバガバなやつ。１度、内から外に出たポート番号あてに、外部から通信がきたらそれを許可する。つまり判断基準がポート番号のみ。
*シンメトリックNAT：宛先ごとに異なるポート番号を使うNAT。そのためSTUNとの相性は悪い。STUNで得たIPアドレスとポート番号は、あくまでもSTUN宛の情報。異なる宛先には異なるポート番号を使うので、ホールパンチングを実行しても実際に相手と使うポート番号は違うので、ステートフルインスペクションに引っかかってしまい通信ができなくなる。
*ホールパンチング：ステートフルインスペクションの対策として、あらかじめ相手側に通信を図りルータに内から外の通信として記憶させる。そうすれば、相手側からきた通信を許可できるようになる。
なお、最初のホールパンチングの通信は相手にブロックされても問題ない。あくまでも自分側の機器がその相手と通信したよという情報を記憶できればブロックされても問題ない。
*TURN:シンメトリックNATの場合、ホールパンチングは不発に終わる。その解決策を提供するのがTURN。仕組みとしては、あらかじめ双方の端末からTURNサーバとセッションを作っておく。TURNはそのセッションを使い双方の中継処理をする。そうすれば、相手側のポート番号が動的に変わってもTURNでそれを吸収できる。手順↓
１．クライアントはTURNサーバにIPアドレスとポートの払い出しを求める
２．TURNから配られたIP、ポートをSIPなどの内部情報に登録して使う
３．２で得た情報をお互いが把握して、お互いがTURNサーバ宛てに送信する
４．TURNがセッション情報から適切なクライアントにパケットを振り分ける。
つまり、クライアントはお互いの実際のIPアドレスは知らないし、知る必要もないということ。なので、シンメトリックでポートが不安定な環境でもTURNを挟めば安定して通信ができるようになる
p.5 STUNサーバはNATより外側に配置しないと意味ないのでは？でもA社は内側にある。どうやってグローバルIPとポート番号知るの？
A.STUNサーバにグローバルIPアドレスを割り当てる。それに対してクライアントがリクエストを送れば、STUNサーバ自体が内部にあっても、トラフィックの流れとしてはNATを越えることができる。なので、STUNサーバ自体が内側に配置されていも機能する仕組みになっている。
また、設問の図をみるとNATよりも内側に見えるが読み進めていくと、STUNサーバの接続先はL2SW1とL2SW2であることが分かる。つまり、実質NATよりも外側に配置されていることになる。
p.5 ISP2を経由してもそのDNS機能を提供できるように、ドメイン登録事業者に定義の追加を依頼する。
A社のDNSサーバとして、現状のISP１のIPアドレスと新規のISP２のIPアドレスを割り当てる。しかし、そのままだと新規のISP２のIPアドレスには届かない。なので、上位ドメイン登録事業者に、A社のDNSサーバのFQDNに対するAレコードとしてISP２のIPアドレスも登録する。そうすれば、ISP１に障害が起きてもA社のDNS名前解決機能は維持し続けるのでユーザからの通信も維持することができる。
p.6 WebRTC
ユーザのブラウザ同士が、データ通信においてサーバなどを挟まずに直接P2Pビデオ通話や音声通話をする技術。
今まではYouTubeなどのように、YouTubeサーバに動画などの情報を取りに行っていた。しかし、WebRTCであれば、最初のきっかけはWebサーバなどを使うが実際のデータ通信はユーザ同士で直接やり取りする。これにより、回線負荷やサーバ負荷を抑えることができる。
p.6 APをダウンロードしたブラウザ
「URLを開いて、プログラムのコードをブラウザのメモリ上に読み込んだ状態」のことを、いっちょまえに「APをダウンロードした」と表現しているだけ。
WebRTC以前は、専用の .exe をダウンロードしてインストールしたり、ブラウザのプラグイン（拡張機能）をインストールしなければならなかった。でも、WebRTCではURLを開けば簡単に利用できますよ！というのを強調したいがための表現。
p.7 ホールパンチ：ステートフルインスペクションの対策として、あらかじめ相手側に通信を図りルータに内から外の通信として記憶させる。そうすれば、相手側からきた通信を許可できるようになる。
なお、最初のホールパンチングの通信は相手にブロックされても問題ない。あくまでも自分側の機器がその相手と通信したよという情報を記憶できればブロックされても問題ない。
p.7② 取得したIPアドレスとブラウザ自身のIPアドレスを通信相手のAPへ通知する
Q.なんで、ブラウザ自身のIPアドレスも通知するの？グローバルIPアドレスだけで十分じゃない？
A.「通信相手が、同じ会社の同じ部屋（同じLAN内）にいるかもしれないから」。同じLANにいる場合はわざわざNATを越えたりする必要がないので、最適経路でやりたいよね！ということでプライベートIPアドレスも通知している。
p.7 ③通信相手との通信を試み、相互に通信が成功した場合に、その宛先IPアドレスの組み合わせを最適ルートとする
Q.プライベートIPアドレスは異なる会社でも重複して使うことができる。そのため、社外との通信だが同じプライベートIPアドレスをもつ社内の無関係の人と通信してしまう可能性があるのではないか？
A.SDPオブジェクトの交換時に、実は使い捨てのIDやパスワードなどを設定している。そのためプライベートIPアドレスの重複がおきてもID、パスワードなどの整合性がとれないと通信を確立することができない。そうなれば自ずとグローバルIPのほうを採用すればいいよねという流れになる。
p.8 IP-PBX
Q.IP-PBXってそもそもなに？
A.IP-PBXとは、通話を実装するための機器。そもそもPBXとは、外線と内線を収容したりする機器。それにIPの機能、つまりVoIPゲートウェイの機能が付加されたものがIP-PBX。これにより、内線同士の通話、外線と内線の通話、電話網とIP網での通話など、さまざまな種類の通話をサポートすることができる。
p.8 HTTP GET Upgrade:websocket
HTTPで行っている通信をWebSocketに切り替えたいです！という要求メッセージ。もし、相手側がそれを承諾するなら101 Switching Protocolsを返す。
p.9 B2BUA（Back-toBack User Agent）
ユーザ同士のP2P通信ではなく、間に仲介役を挟む方式。これをすることで、ユーザは相手側のユーザIPは仲介役のIPになる。そのためP２Pのような直接通信じゃなくなる。逆をいえばユーザはSTUNやTURNをつかって自分のグローバルIPを通知する必要がなくなる。なぜならB2BUAが変換してくれるから。
