目次

• 目次
• はじめに
• Internet Protocol
• アドレス変換技術
• Network Address Translation
• Network Address Port Translation
• NAPT の種類
• Full Cone NAPT
• Restricted NAPT
• Port Restricted NAPT
• Symmetric NAPT
• NAPT の課題
• 通信接続技術
• NAPT Traversal
• UDP Hole Punching
• Session Traversal Utilities for NAPT
• Traversal Using Relays around NAPT
• Interactive Connectivity Establishment
• IPv4/IPv6 の相互接続技術
• DualStack
• Translator
• Tunneling
• まとめ
• 参考・引用

はじめに

インターネットを介した通信は、WEB サービス、モバイルアプリケーション、IoT 等、様々な分野で利用されています。 ネットワークアプリケーションの多くは Internet Protocol（IP） と呼ばれる仕組みによって実現されています。 IP による通信は、データを相手端末に送り届けるための最も基本的な方式であり、現代のインターネットそのものを成り立たせています。

本来、IP 通信はエンドツーエンドの接続性、すなわち送信側と受信側が直接データをやり取りできることを前提に設計されています。

しかし、実際のインターネット環境では IP 通信を妨げる様々な障壁が存在するため、単に IP アドレスを指定すれば相手と接続できるというわけではありません。 特に IP によるエンドツーエンド通信の大きな障壁となっているのが、NAT/NAPT やファイアウォールの存在です。 これらは、ネットワーク内のセキュリティ確保や IP アドレスの節約 といった目的で広く導入されています。

一方で、NAT/NAPT は、配下の端末を外部から隠蔽する特性があり、「どのように相手と接続するか」という接続性の問題を引き起こします。

今回のブログでは、IP 通信の発展と課題、それらの課題を解決するために登場した代表的な通信接続性を実現する技術について紹介したいと思います。

Internet Protocol

Internet Protocol（IP）の仕組みについては こちら のブログで詳しく紹介しています。

• Orenge Diary TechBlog - インターネットの仕組みと TCP/IP

IP では、IP アドレスと呼ばれる「インターネット上の住所」となる識別子を用いて相手端末と通信します。 IP アドレスは、ネットワーク上の 識別子（ID）と位置情報（Locator） の両方の意味合いを持つため、「どの端末がどこにあるのか」を一意に特定することができます。

IP には、一般に利用されている Internet Protocol version 4（IPv4） と、普及傾向にある Internet Protocol version 6（IPv6） の 2 つのバージョンがあります。

IPv4 アドレスは 2 進数 32 桁で表現されるため、割り当て可能なアドレス数は $2^{32}$ 個（= 約 43 億）です。 これは一見膨大な数に見えますが、世界人口は 70 億人を超え、一人当たりの端末所有数も増えていることから、インターネットに接続される全ての端末に一意にアドレスを割り当てることができないとされています。

• Cisco Annual Internet Report (2018–2023) White Paper.

IPv4 の枯渇問題が懸念されたことで、1994 年頃から次世代プロトコルとして IPv6 が検討されはじめました。 IPv6 アドレスは、2 進数 128 桁で表現されるため、割り当て可能なアドレス数は $2^{128}$ 個（= 約 340 澗 282 京 366 兆）に及び、地球上の砂粒の何兆兆倍という天文学的なスケールになります。

従って IPv6 を使用すれば、全ての端末に対して一意にアドレスを割り当てることができる上、枯渇の心配もありません。

しかし、主流の IPv4 と IPv6 ではパケットの構造が異なることから互換性が無いため、IP バージョン相互運用の問題を引き起こしています。

アドレス変換技術

アドレス変換技術は、主に IPv4 アドレスの削減や、端末のセキュリティを確保することを目的として導入された技術です。

従来、IP のバージョンとして IPv4 が広く利用されてきましたが、アドレス数に制限があるためインターネットに接続する全ての端末に一意なアドレスを割り当てることが困難です。

この問題を受け、1990 年代後半から 2000 年代初頭にかけて IPv4 アドレスを節約するために、アドレス変換技術として、NAT（Network Address Translation）/ NAPT（Network Address and Port Translation）が提案・導入されました。

• RFC 2663: IP Network Address Translator (NAT) Terminology and Considerations

Network Address Translation

NAT（Network Address Translation）は、プライベート IP アドレスをグローバル IP アドレスに変換する技術です。

IP アドレスの枯渇問題を受け、現在のインターネットは、グローバルネットワークと複数のプライベートネットワークに分離 することで、アドレスの消費を削減する仕組みとなっています。

グローバルネットワークで用いられるアドレスはグローバル IP アドレスと呼ばれ、広域ネットワーク網（WAN：Wide Area Network）で利用されます。

また、プライベートネットワークで用いられるアドレスはプライベート IP アドレスと呼ばれ、主に家庭内や社内等のローカルネットワーク網（LAN：Local Area Network）で利用されます。 プライベート IP アドレスは同一プライベートネットワーク上でのみ一意に定まります。

通常、端末はプライベートネットワークに接続され、プライベート IP アドレスを取得します。 そして、インターネットにアクセスする際に、NAT を用いて一意なグローバル IP アドレスに変換することでネットワーク接続を可能にしています。

一方、NAT はグローバル IP アドレスが一つしかないため、プライベート IP アドレスを使用する端末がネットワーク内に複数ある場合、それらの端末は同時にインターネットに接続することが困難になります。

Network Address Port Translation

NAPT（Network Address Port Translation は、端末が利用する IP アドレスとポート番号を同時に変換する 技術です。

NAT は、グローバル IP アドレスが一つしかないため、プライベート IP アドレスを使用する端末がネットワーク内に複数ある場合、それらの端末は同時にインターネットに接続することができません。 それだけでなく、NAT はグローバル IP アドレスとプライベートアドレスを 1 対 1 で変換するため、IP アドレスの枯渇問題が本質的に解決されていません。

NAPT はアドレス変換の際、IP アドレスに加え、端末が利用する TCP や UDP のポート番号も同時に変換します。 そのため、NAPT は単一のグローバル IP アドレスを複数のプライベート IP アドレスで併用することが可能であり、プライベートネットワーク内の複数の端末は、同時にインターネットへ接続することができます。

LAN に存在する端末がインターネットに向けて通信を開始すると、ゲートウェイとして介在する NAPT ルータがデータグラム内の送信元 TCP/UDP ポート番号をユニークなエフェメラルポート番号に書き換えます。 そして、送信元のプライベート IP アドレスをグローバル IP アドレスに変換し、ポート番号と一緒にインターネットへ送り出します。

今日では、この NAPT の機能が一般のルータに組み込まれているため、我々は普段からアドレス変換の仕組みを利用して、インターネットに接続していることになります。

また、NAPT は IPv4 アドレス削減の他にも、グローバルネットワークから隠蔽されたプライベートネットワークを作成するため、セキュリティが向上するというメリットがあります。 NAPT には、IP フィルタリングやポートフィルタリング等の設定ができるためファイアウォールとしても機能します。

このため、家庭内の端末に対して、見ず知らずの外部ネットワーク端末から接続されることがないわけです。

NAT と NAPT は同義で利用されることが多いですが、ほとんどの場合は NAPT を指します。 以後、NAT/NAPT はいずれも NAPT と呼ぶことにします。

NAPT の種類

NAPT は、変換の際のマッピングとフィルタリングの規則より Full Cone NAPT、Restricted NAPT、Port Restricted NAPT、Symmetric NAPT の 4 種類に分類されます。

• RFC 3489: Through Network Address Translators (NATs)

マッピングの規則とは、NAPT 配下の端末が NAPT 外部と通信した際にマッピングテーブルに保持されるエントリの変換規則です。 フィルタリングの規則とは、NAPT 外部から NAPT 配下の端末に宛てられたパケットのフィルタリング規則です。

Cone 型 NAPT では、通信を行う外部端末の宛先に関わらず、単一のエントリを作成します。

一方の Symmetric 型 NAPT では、外部端末の宛先毎にエントリを生成するため、エントリが存在する宛先からのアクセスのみを受け入れます。

Full Cone NAPT

Full Cone NAPT は、一度も通信したことのない相手 からでもパケットを受け取る という特性を持ちます。

NAPT のフィルタリングルールには常に *:* (any) が指定されており、「内部アドレス:ポート」を「外部アドレス:ポート」の変換で固定します。 これにより、マッピングテーブルが維持され続ける限り、外部の全てのホストからのパケットを受け入れることができます。

### External Network I/F: eth1
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source "[GLOBAL_IP_ADDRESS]"
iptables -t nat -A PREROUTING -i eth1 -j DNAT --to-destination "[PRIVATE_IP_ADDRESS]"

Restricted NAPT

Restricted NAPT は Cone NAPT の一種で、一度でも通信したことのある IP アドレス であればパケットを受け取る という特性を持ちます。

NAPT のフィルタリングルールには IP:* (Port any) が指定されており、マッピングテーブルに変換情報が存在すれば、それに従って相手端末からのパケットを受け入れることができます。

### External Network I/F: eth1
iptables -t nat -A POSTROUTING -o eth1 -p udp -j SNAT --to-source "[GLOBAL_IP_ADDRESS]"
iptables -t nat -A PREROUTING -i eth1 -p udp -j DNAT --to-destination "[PRIVATE_IP_ADDRESS]"
iptables -A INPUT -i eth1 -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth1 -p udp -m state --state NEW -j DROP

Port Restricted NAPT

Port Restricted NAPT も Cone NAPT の一種で、一度でも通信したことのある IP アドレスとポート番号 であればパケットを受け取る という特性を持ちます。

NAPT のフィルタリングルールには IP:Port が指定されており、マッピングテーブルに変換情報が存在すれば、それに従って相手端末からのパケットを受け入れることができます。

Restricted NAPT に加えて、変換時にポート番号のフィルタリングが掛けられるため、Cone 型 NAPT の中で最も通信時の制約が強いと言えます。

### Internal Network I/F: eth0
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source "[GLOBAL_IP_ADDRESS]"

Symmetric NAPT

Symmetric NAPT は、外部端末の宛先毎にマッピングエントリを生成し、エントリが存在する宛先からのパケットのみを受け入れる という特性を持ちます。

Cone 型 NAPT と異なり、宛先毎にフィルタリングルールを適用するため、相手端末数が $N$ 台の時、ルールの数も $N$ 個となります。 従って、同じ「内部 IP:ポート」からの通信であっても、宛先が異なれば外部へのマッピングは異なります。

NAPT の中では、最も厳格なフィルタリング特性を持つため、通信時の制約も非常に強くなります。

### Internal Network I/F: eth0
### External Network I/F: eth1
echo "1" >/proc/sys/net/ipv4/ip_forward
iptables --flush
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE --random
iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

NAPT の課題

NAPT を利用することで、IP アドレスの節約やネットワーク内のセキュリティ確保を実現することができますが、グローバルネットワークに存在する端末は、NAPT による変換前のポート番号を知る術がないため、プライベートネットワーク内の端末へ通信を開始することが極めて困難になります。

そのため、外出先から家庭内の端末に接続（WAN → LAN 通信）したり、家庭からオフィスの端末に接続（LAN 間通信）したりすることができない といった課題が生じます。

このような課題は NAPT 越え問題 と呼ばれ、アドレスとポート番号を同時に変換する NAPT 機構において、避けられない問題です。 NAPT 越え問題は、外出先等、LAN 外からアクセスする場合や、端末の NAPT を跨いだ IP 通信時に障壁となります。

NAPT の種類や NAPT 越えについては、以下の記事でもイラストベースで分かりやすく解説してくれています。

• 「NAT」「NAT 越え」「NAT タイプ」ってなーに？

通信接続技術

NAPT 越え問題や IP バージョンの非互換性によって生ずる、IP 通信におけるエンドツーエンド接続の課題は、包括的に 通信接続問題 と呼ばれます。

また、通信接続問題を解決する技術は 通信接続技術 と呼ばれ、特に VoIP（Voice over Internet Protocol）や P2P（Peer-to-Peer）通信等、エンドツーエンドの接続性を必要とするアプリケーションにおいて重要になります。

NAPT 越え問題を解決する技術は、一般に NAPT Traversal と呼ばれ、代表的なものに UDP Hole Punching、STUN（Session Traversal Utilities for NAPT）、TURN（Traversal Using Relays around NAPT）、ICE（Interactive Connectivity Establishment）があります。

デュアルスタック環境において、異なる IP バージョン間での通信を可能にする技術としては、DualStack、Tunneling、Translator があります。

NAPT Traversal

UDP Hole Punching

UDP Hole Punching は、プライベートネットワーク内部から通信を行なった後、一定期間のみグローバルネットワークからの通信を許可するという NAPT の性質を利用して、NAPT 越えを実現します。

NAPT 配下に存在する端末がグローバルネットワークへ通信を開始する際、NAPT はパケットの IP アドレスとポート番号を変換します。 その際、NAPT は相手端末からのレスポンスを NAPT 配下の端末へ転送するため、変換した IP アドレスとポート番号の情報をマッピングテーブルに保持します。

しかし、マッピングテーブルは一定期間通信が行われない場合削除されるため、UDP Hole Punching は一定間隔で、軽量かつベストエフォートな UDP パケットをグローバルネットワークにある端末へ送信し続けることでマッピングテーブルを維持します。 これにより、外部に存在する端末から通信を受け入れることが可能になり、通信接続問題を解決します。

UDP Hole Punching による NAPT 越えは、いずれかの端末がグローバルネットワークに存在することが前提となっています。 そのため、両端末がともに NAPT 配下に存在する場合は、互いに NAPT が生成した変換後のポート番号を知ることができないため、UDP Hole Punching のみでの NAPT 越えは困難です。

Session Traversal Utilities for NAPT

UDP Hole Punching では、両端末がともに NAPT 配下に存在する場合、NAPT によって生成された変換情報を互いに知ることができないため、NAPT 越えが困難な課題があります。

STUN（Session Traversal Utilities for NAPT）は、STUN サーバをグローバルネットワークに設置して、双方の変換情報を記録し、相手端末に通知することで通信接続性を実現する軽量なクライアントサーバ型プロトコルです。 STUN は RFC8489 で標準化されています。

STUN プロトコルをサポートするクライアント（STUN クライアント）は、一般に、VoIP やインスタントメッセージ等のアプリケーションが利用するプロトコルライブラリに含まれています。

STUN クライアントは NAPT による IP マスカレードが行われるプライベートネットワーク内で動作し、通信を開始する前に STUN サーバに STUN Binding Request を UDP で送信します。 STUN サーバは双方のリクエストに対し、他方のグローバル IP アドレスとポート番号を STUN Binding Response によって通知します。

これにより、STUN クライアントが通信相手の変換情報を相互に得るため、両端末が NAPT 配下に存在する場合でも、UDP Hole Punching を利用して通信接続性を実現することができます。

しかし、いずれかの端末が Symmetric 型 NAPT 配下に存在する場合、STUN サーバとの通信に利用するマッピング情報と相手端末との通信に利用するマッピング情報が異なるため、STUN による NAPT 越えは困難です。 これは、Symmetric 型 NAPT のフィルタリングルールが宛先毎に適用されるためです。

pystun3 コマンドを利用すると、自身の端末が所属するプライベートネットワークの NAPT タイプを調べることができます。

$ pip3 install pystun3

import stun

nat_type, external_ip, external_port = stun.get_ip_info() # Full Cone / Restric NAT / Restric Port NAT / Symmetric NAT

print(f"NAT Type: {nat_type}")
print(f"External IP: {external_ip}")
print(f"External Port: {external_port}")

NAT Type: Restric Port NAT
External IP: None
External Port: None

Traversal Using Relays around NAPT

STUN では、いずれかの端末が Symmetric 型 NAPT 配下に存在する場合、通信接続性を実現することができません。

この問題を解決し、Symmetric 型 NAPT が存在する場合でも、NAPT 越えを実現する NAPT Traversal として TURN（Traversal Using Relays around NAPT）が提案されました。 TURN は RFC8656 で標準化されています。

TURN はグローバルネットワークに存在する TURN サーバが、端末間の通信を中継することで Symmetric 型 NAPT 配下に存在する端末との通信をリレーします。

TURN をサポートするクライアント（TURN クライアント）は、最初に TURN Allocate Request を TURN サーバに送信して認証を受けます。 認証に成功すると TURN Allocate Success Response により、TURN サーバが割り当てたリレーに用いるための IP アドレスとポート番号を XOR-RELAYED-ADDRESS として付与し、NAPT のグローバル IP アドレスを XOR-MAPPED-ADDRESS として付与します。 TURN では、TURN クライアントと TURN サーバ間で送受信するデータはポート番号 3478 でカプセル化されます。

TURN の Send and Data メカニズムでは、クライアントは Create Permission Request により、相手端末との通信開始を TURN サーバに対して依頼します。 相手との通信が許可されると Create Permission Response にて、相手のグローバル IP アドレスとポート番号が通知されます。 TURN サーバから Create Permission Response を受けると XOR-PEER-ADDRESS に相手のグローバル IP アドレスとポート番号を含めて TURN サーバに Send Indication を送信します。 TURN サーバがクライアントから Send Indication を受信すると、相手先とのリレーに用いる XOR-RELAYED-ADDRESS を送信元として相互に UDP パケットを交換します。

両端末が前述の手順を行うことで、TURN サーバを介したリレー通信によって、Symmetric 型 NAPT が存在する場合でも NAPT 越えを実現します。

しかし、TURN は通信の際に、常に TURN サーバを経由した通信が必要となるため、経路冗長化の問題を引き起こします。

実際に TURN サーバを利用するアプリケーションの例として、モンスターストライクのマルチプレイが挙げられます。

• モンスターストライクのリアルタイム通信を支える技術

Interactive Connectivity Establishment

TURN では、TURN サーバが端末間で中継処理を行うことで NAPT 越えを実現できますが、通信経路が冗長になるという問題が生じます。

ICE（Interactive Connectivity Establishment）は、STUN や TURN 等の複数の NAPT Traversal を包括した通信接続技術であり、端末が存在するネットワーク環境に応じて適切な NAPT 越えを実現します。 ICE は RFC8445 で標準化されています。

ICE をサポートするクライアント（ICE クライアント）は、TURN サーバに TURN Allocate Request を送信し、Candidate と呼ばれる通信相手の候補と、自身のネットワーク情報を収集します。 ICE クライアントは収集した Candidate から SDP（Session Description Protocol） と呼ばれる、ストリーミング送信を開始する際に、必要なパラメータを伝達するためのデータを生成します。

両者が Candidate から SDP を生成すると、SIP（Session Initiation Protocol）、WebRTC（Web Real Time Communication）、XMPP（eXtensible Messaging and Presence Protocol） 等のプロトコルによって Candidate を交換します。 クライアントが通信相手から SDP を受信すると、取得した全ての Candidate に対して STUN Binding Update を送信して接続確認を行います。

これにより、双方の端末は相手と通信する際に、NAPT の種類に応じて TURN サーバを経由して通信するか、直接通信が可能かを判別し、端末が存在するネットワークに最適な NAPT 越えを実現します。

マサチューセッツ工科大学の 論文 では、市場に出回っている NAPT の約 82% は Cone 型 NAPT であることが述べられています。（かなり前の論文なので、現在は動向が変わっている可能性有り）

• Peer-to-Peer Communication Across Network Address Translators

IPv4/IPv6 の相互接続技術

DualStack

DualStack は、単一機器に IPv4 と IPv6 の仕様の異なる 2 つのプロトコルスタックを共存させる技術です。 端末が IPv4/IPv6 の両バージョンに対応するため、それぞれの通信を行うソフトウェアスタックを用意することで、通信相手の IP バージョンに応じた通信を行うことが可能になります。

DualStack では、端末を IPv4 と IPv6 の両方に対応させることで、通信接続性を実現し、IP バージョンの異なる双方のネットワークに存在する端末間でのエンドツーエンド接続が可能になります。

DualStack では、IPv4 と IPv6 の両 IP バージョンへの対応を行うために、カーネル内のネットワークスタックに改良が必要となります。 このため、従来型の機器では異なる IP バージョンに対応することが困難であり、網羅的な通信接続性は実現されません。

Translator

DualStack では、一部の端末で IPv4/IPv6 の両 IP バージョンへの対応が困難な問題がありました。

Translator は端末が DualStack を実装しておらず、特定の IP バージョンのみしか扱えない場合に、中継サーバが IP ヘッダを変換することで通信接続性を実現します。

例えば、IPv4 のみを扱う端末から IPv6 のみを扱う端末へ通信を開始する場合、中継サーバが事前に端末の IPv4 アドレスと IPv6 アドレスの経路情報を保持しておくことで、IPv4 ノードは中継サーバを経由して、IPv6 ノードとの通信が可能になります。 中継サーバは主に Proxy 方式、Network Address Port Translation-Protocol Translation（NAPT-PT）方式、Transport Relay Translator（TRT）方式によって実装されます。

• Proxy 方式
  • Translator がアプリケーション毎に送信元の代理となって通信する
• NAPT-PT 方式
  • Domain Name System-Application Layer Gateway（DNS-ALG）機能により、DNS と連携し、プロトコルのアドレスやポート番号を動的に変換して通信する
• TRT 方式
  • トランスポート層でセッションをインターセプトし、TCP や UDP 間通信の代理となって各ネットワークの送信先へ送る

Translator は、あらゆる端末を短期間で IPv6 に対応させることができますが、IPsec（Security Architecture for Internet Protocol）や SIP 等の一部のプロトコルは IP ヘッダを変換することができません。 そのため、DualStack と同様に網羅的な通信接続性は実現されません。

Tunneling

Tunneling は端末間通信の際に、ネットワーク経路上に存在するルータが特定の IP バージョンのみしか扱えない場合において、データのカプセル化を行うことで通信接続性を実現する技術です。 ここで、カプセル化とは、パケット全体を別の通信プロトコルに埋込んで通信する技術を指します。

両端末は IPv6 でデータの送受信を行いたいが、経路上に存在するルータが IPv4 パケットしか扱えない場合、IPv6 パケットを IPv4 パケットにカプセル化して IPv4 ネットワーク上で IPv6 を使用する、IPv6 over IPv4 通信を行います。 両端末が IPv4 でデータの送受信を行いたいが、経路上に存在するルータが IPv6 パケットしか扱えない場合は、IPv4 パケットを IPv6 パケットにカプセル化して IPv6 ネットワーク上で IPv4 を使用する、IPv4 over IPv6 通信を行います。

これにより、宛先でパケットがデカプセル化される際に、中身のデータを取り出すことで、送信元端末から発信された本来の IP バージョンでパケットの送受信を行うことができます。

ただし、Tunneling はネットワーク経路上の IP バージョン差異に着目した技術となっており、エンド端末が異なる IP バージョンを利用している場合は、前述の DualStack や Translator を組み合わせる必要があります。

また、Tunneling は NAPT 越え問題を考慮していないため、IPv6 ネットワーク上の端末から IPv4 プライベートネットワーク上の端末へ通信を開始するようなケースには対応していません。

まとめ

今回のブログでは IP 通信における NAPT 越え問題や、IP バージョンの非互換性によって生じる通信接続問題について紹介しました。 通信接続問題を如何に解決するかは、VoIP や P2P 通信等、エンドツーエンドの接続性を必要とするアプリケーションにおいて重要な課題です。

IP に起因した課題を解決するために様々な通信接続技術が提案されていますが、各技術には課題も存在するためトポロジに合わせた適切な組み合わせが必要になります。 特にリアルタイム性を要するストリーミングアプリケーションやコンテンツ配信サービス、IoT の分野では、端末間のネットワーク距離を短縮した通信が要求されます。

そのため、このようなサービスを開発するエンジニアは IP における接続性の課題や、どのようにそれらの課題を解決してエンド間通信を提供するのかを本質的に理解しておくことが重要です。

参考・引用

• RFC791: INTERNET PROTOCOL
• RFC8200: Internet Protocol, Version 6 (IPv6) Specification
• RFC2663: IP Network Address Translator (NAT) Terminology and Considerations
• RFC3489: STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
• RFC8489: Session Traversal Utilities for NAT (STUN)
• RFC8656: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
• RFC8445: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
• RFC8866: SDP: Session Description Protocol
• RFC3261: SIP: Session Initiation Protocol
• RFC7478: Web Real-Time Communication Use Cases and Requirements
• RFC6120: Extensible Messaging and Presence Protocol (XMPP): Core
• How to simulate different NAT behaviours