Acheter ou Renouveler
Acheter ou Renouveler
annuler
Activer les suggestions
La fonction de suggestion automatique permet d'affiner rapidement votre recherche en suggérant des correspondances possibles au fur et à mesure de la frappe.
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 
cancel
Créer un nouvel article
6692
Visites
6
Compliment
0
Commentaires

シスコ コラボレーションにおける ICE の概要

Kenichi Ogami
Cisco Employee
Cisco Employee

le ‎2019-04-21 08:18 PM


 

はじめに

ICE (Interactive Connectivity Establishment) は SIP や WebRTC クライアントなどの NAT 越え (NAT トラバーサル) を実現するメカニズムです。ICE は RFC 5245 で標準化されており、STUN (Session Traversal Utilities for NATs) と TURN (Traversal Using Relays around NAT) プロトコルを使います。

シスコのコラボレーションソリューションでは、Cisco Expressway へ登録したエンドポイント同士の通話、CMS (Cisco Meeting Server) と Microsoft Office 365 との通話、MRA (Mobile and Remote Access) のメディアパス最適化 (Media Path Optimization)、CMS への WebRTC 接続など、インターネットから Cisco Expressway を経由したコールで ICE が用いられます。

本ドキュメントでは、これらのシスコのコラボレーションソリューションで使われる STUN、TURN、ICE のプロトコルの動作の概要を説明します（説明のために一部簡略化している箇所もありますが、予めご了承ください）。

  

SIP の NAT 越え

NAT (Network Address Translation)

NAT (Network Address Translation) は IP アドレスを変換する技術です。プライベート IP アドレスとグローバル IP アドレスを関連付けて変換し、グローバル IP アドレスの節約や、社内ネットワークのセキュリティを高めることができます。

nat.jpg

 

NAT を実現するルータは、ルータ内部に NAT テーブルを保持し、プライベート IP アドレスとグローバル IP アドレスのマッピングを行います。Dynamic NAT (NAPT) の場合、一時的なエントリーを作成し、一定時間通信がないとエントリーが削除されます。

以下の例では、クライアント (192.168.1.1) が、サーバ (200.1.1.1) と通信する際に、NAT を経由している例となります。クライアントのプライベート IP アドレス 192.168.1.1:6344 はグローバル IP アドレス 100.1.1.1:24005 に変換されています。サーバは応答として、100.1.1.1:24005 にパケットを送信すると NAT テーブルにエントリーが残っている場合は 192.168.1.1:6344 に変換され、クライアントにパケットが届きます。

 

nat2.jpg

 

SIP と NAT

SIP (Session Initiation Protocol) は、SIP クライアント同士でセッションを確立し、メディア情報が記載されている SDP (Session Description Protocol) を交換することによって、マルチメディア通信を実現するプロトコルです。

SIP による通信の問題点の一つとして、SIP の NAT 越えがあります。通常の NAT ルータはネットワークレイアの IP アドレスを変換することはできますが、アプリケーションレイアである SIP メッセージに記載されている SDP の IP アドレスを書き換えることができません。そのため、相手の IP アドレスに向かって RTP (Real-time Transport Protocol) などのメディアパケットを送信しても相手に届かないという問題が発生します。

以下は、クライアント A (プライベート IP: 192.168.1.1) とクライアント B (プライベート IP: 172.16.2.2) が SIP サーバを経由して通信する例となります。この場合、INVITE と 200 OK (INVITE) に記載されている SDP が NAT で変換されないため、お互いにプライベート IP に送信しようとして RTP の送信に失敗しています。結果として SIP セッションは確立されますが、通話は無音になってしまいます。

sip_natp.jpg

 

SIP の NAT 越えの技術

SIP の NAT 越えの技術の例として、SIP NAT、SIP B2BUA (Back-to-back User Agent) / SBC (Session Border Controller)、UPnP (Universal Plug and Play)、ICE/TURN/STUN があります。

sip_nat_traversal.jpg

 

SIP-NAT の例

SIP-NAT の場合、NAT ルータがネットワークレイアの IP アドレスだけではなく、SIP メッセージの IP アドレスも変換します。この方法を用いる場合、経由する NAT ルータ全てが SIP-NAT 機能をサポートしていなければならないことと、SIP メッセージの中では独自 SIP ヘッダを含め様々な SIP ヘッダで IP アドレスが使用されているため、相互接続性の問題があります。

sip_nat_ex.jpg

 

STUN/TURN/ICE

STUN (Session Traversal Utilities for NAT)

STUN (Session Traversal Utilities for NAT) は、RFC 5389 で標準化されているプロトコルです。旧バージョンは RFC 3489 (STUN: Simple Traversal of User Datagram Protocol through NAT) です。STUN は NAT を越えるツールとして用いられています (STUN だけでは NAT は越えられない)。クライアント・サーバとして動作し、サーバはクライアントから受信した STUN リクエストに対して、NAT の IP アドレスとポート番号を記載し、STUN レスポンスを返信します。クライアントはこの STUN レスポンスを見て、サーバ側からどの IP アドレスとポート番号が見えているか (=NAT のグローバル IP アドレスとポート番号) を知ることができます。STUN (TCP/UDP) はデフォルトでポート番号 3478 が使われます。

stun.jpg

  

TURN (Traversal Using Relays around NAT)

TURN (Traversal Using Relays around NAT) は RFC 5766 で標準化されているプロトコルで、NAT 背後にいる TURN クライアントが TCP または UDP を介して通信できるようにするための STUN を拡張プロトコルです。TURN クライアントは、コールのメディアの要素にリレーを割り当てるように TURN サーバに要求します。各メディアの要素 (例: IPv4/IPv6、音声/ビデオ、RTP/RTCP) に 1 つのリレーが必要となります。TURN サーバは、NAT 背後にいる TURN クライアントがアクセス可能なグローバル IP アドレスをリレーとして割り当てます。TURN クライアント同士は、TURN サーバでデータをリレーさせることによって通信を行います。TURN はデフォルトで STUN と同じポート番号 (TCP/UDP: 3478) が使われます。

 

リレーの確保 (TURN Allocate リクエスト)

TURN クライアントは、Allocate リクエストを使って TURN サーバにリレーのリソースの割当を要求します。TURN クライアントから TURN サーバに Allocate リクエストを送ると、認証が必要な場合は TURN サーバは Realm や NONCE などのパラメータを付与してダイジェスト認証のために 401 Unauthorized レスポンスを返します。TURN クライアントは、ユーザ名、パスワード、Realm、NONCE をハッシュしたものを Message-integrity に付与して再度 Allocate リクエストを TURN サーバに送信します。TURN サーバは、その値をチェックして、サーバ内で計算した値と一致したら Allocate サクセスレスポンスを TURN クライアントに返信します。TURN サーバは、Allocate サクセスレスポンスに TURN サーバが割り当てたリレーの IP アドレスとポート番号を XOR-RELAYED-ADDRESS に付与し、NAT ルータのグローバル IP アドレスを XOR-MAPPED-ADDRESS に付与します。

turn.jpg

 

リレーのメカニズム

TURN サーバを使ってデータをリレーするメカニズムとして、以下の 2 つがあります。いずれも TURN クライアントとサーバ間で送受信するデータは、ポート番号 3478 の通信の中でカプセル化されます。

  1. Send and Data メカニズム
    • CreatePermission リクエストで Permission を要求
    • Send Indication、Data Indication メッセージでデータを送信
    • STUN のヘッダを使うためオーバヘッドが大きい
    • MRA メディアパス最適化 (Media Path Optimization) で Cisco Jabber が利用
  2. Channel メカニズム
    • Channel Bind リクエストで Permission を要求
    • オーバヘッドが少ない (4 バイト)
    • Channel の維持に定期的なリフレッシュが必要
    • Microsoft Office 365 接続で CMS (Cisco Meeting Server) が利用

 

Send and Data メカニズム

以下は Send and Data メカニズムの例です。TURN クライアントは XOR-PEER-ADDRESS に通信したい相手の IP アドレスを設定して CreatePermission リクエストを TURN サーバに送信します。TURN サーバは通信を許可する CreatePermission サクセスレスポンスを返します。その後、RTP などのアプリケーションデータは、Send Indication (クライアント -> サーバ) もしくは Data Indication (サーバ -> クライアント) でカプセル化して送受信されます。

senddata.jpg

 

 

Channel メカニズム

以下は Channel メカニズムの例です。TURN クライアントは CHANNEL-NUMBER にチャネル番号、XOR-PEER-ADDRESS に通信したい相手の IP アドレスを記載し、ChannelBind リクエストを TURN サーバに送信します。TURN サーバは、許可する場合、チャネル番号をピアと紐づけて通信を許可します。その後、RTP などのアプリケーションデータは、Channel Data としてチャネル番号でカプセル化して送受信されます。

 

channel.jpg

 

ICE (Interactive Connectivity Establishment)

概要

ICE (Interactive Connectivity Establishment) は SIP や WebRTC クライアントなどの NAT 越え (NAT トラバーサル) を実現するメカニズムです。ICE は RFC 5245 で標準化されており、STUN (Session Traversal Utilities for NATs) と TURN (Traversal Using Relays around NAT) プロトコルを使います。

ICE は通信相手と通信経路のアドレスの候補 (Candidate) を交換します。相手から受信した Candidate それぞれに対して STUN Binding リクエストを送信して応答がある経路を探し、最適な経路を決定します。

 

Candidate

アドレスの候補である Candidate には以下の種類があります。

  • Host Candidate: ICE クライアント (SIP エンドポイントなど) のローカルの IP アドレスとポート番号
  • Server Reflexive Candidate: NAT ルータのグローバル IP アドレスとポート番号
  • Relayed Candidate: TURN リレーサーバの IP アドレスとポート番号

 

処理の流れ

ICE における大まかな処理の流れは以下の通りです。

ice_flow.jpg

 

以下の例は処理の流れをフローで表したものです。Allocate リクエストで TURN サーバ (Relayed Candidate) や NAT のグローバルアドレス (Server Reflexive Candidate) などの Candidate を収集します。収集した Candidate を SIP/SDP で交換し、相手の Candidate を取得します。取得した Candidate それぞれに対して STUN Binding リクエストを送信して接続確認をします。応答があった経路を使ってメディアを送信します。例ではリレー経由でメディアを送信しています。

  ice_flow2.jpg

 

Candidate の収集

Candidate の収集は、TURN Allocate リクエストを用います。クライアントはローカルの IP アドレス (Host Candidate) および Allocate サクセスレスポンスの XOR-MAPPED-ADDRESS (Server Reflexive Candidate) と XOR-RELAYED-ADDRESS (Relayed Candidate) から Candidate を収集します。

collect_candidate.jpg

 

Candidate の交換

収集した Candidate から SDP を生成して、SIP、WebRTC、XMPP などのプロトコルで交換します。

candidate_exchange.jpg

以下は SIP INVITE と 200 OK (INVITE) で SDP (candidate) を交換している例になります。

candidate_exxhange2.jpg

 

Candidate の整理

相手の ICE サポートの有無、受信した Candidate と自身の Candidate のペアを作成し、優先度の確認などを行います。

 

接続確認

全てのペアに対して STUN Binding リクエストを送信して接続確認を行います。接続確認は、ホストから直接相手の Candidate に送信するとともに、自身の Relay サーバ経由で相手の Candidate に送信します。STUN Binding サクセスレスポンスが返信された経路から最適な経路を見つけます。

以下は一部のパターンを示したものです。

binding_request.jpg

 

以下は、接続確認のフローの例です。この例では、STUN Binding リクエストの直接送信は失敗し、自身および相手のリレーサーバ経由の STUN Binding リクエストに対して STUN Binding サクセスレスポンスを受信しています。

 

binding_request2.jpg

 接続確認は、逆方向も成功する必要があります。

binding_request3.jpg

 

経路の確定

成功した経路から最適な経路が確定すると、USE-CANDIDATE を付与して再度 STUN Binding リクエストを送信し、相手に経路を伝えます。

binding_request4.jpg 

 その後、re-INVITE の SDP に、a=candidate に自身の選択された Candidate のみを記載し、a=remote-candidate に選択された相手の Candidate を記載して送信します。

binding_request5.jpg

確定した経路経由でメディアを送受信します。

binding_request6.jpg

 

参考情報

 
Étiquettes :
Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします

Customers Also Viewed These Support Documents