Expressway は、登録されている SIP および H.323 エンドポイント、およびそれに隣接するすべてのシステムに代わって、ファイアウォール トラバーサル クライアントとして機能できます。 ファイアウォール トラバーサル クライアントとして機能するには、ファイアウォール トラバーサル サーバとして機能するシステムに関する情報を使用して Expressway を設定する必要があります。

これを行うには、Expressway クライアントにトラバーサル クライアント ゾーンを追加し (Configuration > Zones > Zones)、トラバーサル サーバの詳細を使用して構成します。 詳細については、「 トラバーサル クライアント ゾーンの構成 」を参照してください。 複数のトラバーサル サーバに接続する場合は、複数のトラバーサル クライアント ゾーンを作成できます。

Expressway-C か Expressway-E か?

• 通常、Expressway-C はファイアウォール トラバーサル クライアントとして使用されます。 ただし、Expressway-E でもこの役割を担うことができます。

• Expressway クライアントが使用するファイアウォール トラバーサル サーバは Expressway-E である必要があります。

ICE (Interactive Connectivity Establishment) は、SIP クライアントの NAT トラバーサルのメカニズムを提供します。 ICE はプロトコルではなく、TURN (Traversal Using Relays around NAT) や STUN (Session Traversal Utilities for NAT) などのさまざまな技術をまとめたフレームワークです。

これにより、NAT デバイスの背後にあるエンドポイント (クライアント) は、メディアを渡すことができるパスを検出し、各パスを介してピアツーピア接続を確認し、最適なメディア接続パスを選択できるようになります。 使用可能なパスは通常、NAT デバイスで設定されている受信および送信接続の制限によって異なります。 このような動作は、 RFC 4787 で説明されています。

ICE の使用例としては、2 人の在宅ワーカーがインターネット経由で通信することが挙げられます。 2 つのエンドポイントが ICE 経由で通信できる場合、Expressway-E は (NAT デバイスの設定方法に応じて) シグナリングのみを取得し、メディアを取得する必要がない場合があります (したがって、非トラバーサル コールになります)。 開始元の ICE クライアントが非 ICE クライアントに電話をかけようとすると、通話セットアップ プロセスは従来の SIP 通話に戻り、Expressway もメディアを取得するメディア ラッチによる NAT トラバーサルが必要になります。

ICE の詳細については、 RFC 5245 を参照してください。

X12.5 以降では、Interactive Connectivity Establishment (ICE) パススルーをサポートし、MRA 登録エンドポイントが WAN と Cisco Expressway シリーズをバイパスしてエンドポイント間で直接メディアを渡すことができるようになりました。

ICE パススルーの設定の詳細と必要なバージョンについては、 『Cisco Expressway 経由のモバイルおよびリモート アクセス』ガイド の Expressway 設定ガイド ページに記載されています。

TURN サービスは、STUN ネットワーク プロトコルのリレー拡張機能であり、SIP クライアントが NAT デバイスの背後から UDP または TCP 経由で通信できるようにします。

TURN の詳細については RFC 5766 を参照してください。また、基本 STUN プロトコルの詳細については RFC 5389 を参照してください。

各 ICE クライアントは、通話のメディア コンポーネントのリレーを割り当てるように TURN サーバに要求します。 各クライアント間のメディア ストリーム内の各コンポーネントにはリレーが必要です。

リレーが割り当てられると、各 ICE クライアントには、メディアを送受信できる 3 つの潜在的な接続パス (アドレス) が与えられます。

• NAT デバイスの背後にあるホスト アドレス (したがって、NAT の反対側のエンドポイントからは到達できません)。

• NAT デバイス上のパブリックにアクセス可能なアドレス。

• TURN サーバ上のリレー アドレス。

次に、エンドポイントは ICE を介して接続チェックを実行し、通信方法を決定します。 NAT デバイスの構成方法に応じて、エンドポイントは NAT デバイス上の公開アドレス間で通信できる場合もあれば、TURN サーバ経由でメディアを中継しなければならない場合もあります。 両方のエンドポイントが同じ NAT デバイスの背後にある場合は、内部ホスト アドレスを使用してエンドポイント間で直接メディアを送信できます。

メディア ルートが選択された後、選択された接続パスに TURN サーバ経由のルーティングが含まれない場合は、TURN リレーの割り当てが解放されます。

（注）	エンドポイントによって選択された最終的なメディア通信パスに関係なく、シグナリングは常に Expressway 経由で行われます。 TURN サーバは、一方または両方が企業の内部ファイアウォール内にある場合でも、任意の 2 つの ICE クライアント間でメディアを中継できます。 TURN パスワードは管理者パスワードとは異なるパスワードにすることをお勧めします。

機能と制限事項

• X12.6.1 以降、セキュリティ強化により、Expressway-E TURN サーバは汎用 STUN サーバとして機能しなくなり、認証されていない STUN バインディング要求を受け入れなくなります。 これにより、次のようなシナリオが考えられます。

  • シナリオ A: B2BUA を Microsoft 相互運用性の TURN クライアントとして使用する場合 ( 『Cisco Expressway with Microsoft Infrastructure Deployment Guide』で説明されているように)、B2BUA は TURN サーバがアクティブかどうかを確認するための STUN バインディング要求を TURN サーバに送信しません。 つまり、Expressway X12.6.1 からは、B2BUA が到達不可能な TURN サーバの使用を試みることがあり、その結果、 通話が失敗する可能性があります。

  • シナリオ B: 導入されている CMS のバージョンによっては、CMS WebRTC ソリューションが Expressway-E 上の TURN サーバに対して STUN バインド要求を使用する可能性があり、障害が発生します。 したがって、Meeting Server WebRTC を使用する場合は、Expressway バージョン X12.6.1 以降のソフトウェアをインストールする前に、CMS バージョンに互換性があることを確認してください。 バグ ID CSCvv01243 を参照します。 （Expressway-E TURN サーバー設定の詳細については、『Cisco Expressway Web Proxy for Cisco Meeting Server 導入ガイド』を参照してください。）

• 小規模 または 中規模 システムでは、最大 1800 個のリレー割り当てがサポートされます。 これは通常、同時通話の最大制限をサポートするのに十分ですが、ネットワーク トポロジと通話に使用されるメディア ストリーム コンポーネントの数によって異なります。 たとえば、一部の通話では Duo Video が使用され、他の通話では音声のみが使用されます。

• 大規模 システムは最大 6000 個のリレーをサポートします。 ポート多重化が有効になっている場合は 1 つの外部ポートで完全なリレー容量が利用可能になり、ポート範囲が構成されている場合は 6 つの外部ポートに分散されます。 ポート間に分散されている場合、各ポートは 1000 個のリレーの処理に制限されます。

  この制限は厳密には適用されません。 そのため、DNS SRV レコードを作成し、ポートアドレスの範囲ごとに同じアドレスで 6 つの A/AAA エントリを作成することをお勧めします。 レコードを作成したら、Expressway-E TURN サーバの SRV レコードを使用してクライアントを設定します。 TURN 多重化が有効になっている場合は、TURN 要求をリッスンする外部ポートに対してのみ SRV レコードを作成することをお勧めします。

• 大規模 システムでは、デフォルトで 3478 から 3483 までのポート範囲で TURN 要求をリッスンするように TURN サーバを構成できます。 X8.11 以降、TURN 多重化が有効になっている場合、Expressway-E は範囲の最初のポート (通常は UDP 3478) 上のすべての TURN 要求を受け入れます。 Expressway は内部的にこれらの要求をポート範囲に逆多重化します。 TURN クライアントは設定された単一ポートで要求を送信する必要がありますが、大規模な Expressway-E TURN サーバの全容量を利用できます。

• X8.11 以降、Expressway-E は TCP ポート 443 で TURN 要求と Cisco Meeting Server 要求の両方をリッスンできます。Expressway-E はポート 443 経由で接続要求を受信すると、要求の種類に応じて、その要求を TURN サーバまたは Meeting Server Web プロキシに転送します。 その結果、外部ユーザは TURN サービスを使用し、ファイアウォール ポリシーが制限された環境から Meeting Server スペースに参加できるようになります。

  Web 管理者ポートがポート 443 (システム > 管理設定) でリッスンするように設定されている場合、X12.7 より前のバージョンの Expressway では、443 から他の有効なポートに変更する必要があります。 X12.7 以降では、Expressway が専用管理インターフェイスを唯一の管理インターフェイスとして使用するように設定されている場合は、これを行う必要はありません。 つまり、 システム > 管理設定 ページで、 専用管理インターフェースのみを使用する (管理用) が はいに設定されます。

• 大規模 システムでは、TCP 443 TURN サービスが有効になっており、TURN 多重化機能も有効な場合、6000 個の TCP TURN リレーがサポートされます。

• クラスター化された Expressway: 要求された TURN サーバのリレーが完全に割り当てられている場合、サーバは要求元のクライアントに、クラスター内の代替サーバ (現在最も利用可能なリソースを持つ TURN サーバ) の詳細を応答します。

• Expressway の TURN サービスは、単一およびデュアル ネットワーク インターフェイス (高度なネットワーキング オプション経由) でサポートされます。 デュアル ネットワーク インターフェイスの場合、TURN サーバは両方のインターフェイスをリッスンしますが、リレーは Expressway の外部に面した LAN インターフェイスにのみ割り当てられます。

• Expressway-E の TURN サーバは、Microsoft ICE (標準ベースではない) をサポートしていません。 Microsoft Edge Server を通じて登録された Expressway と Microsoft クライアント間の通信を有効にするには、 Microsoft 相互運用性サービス を使用する必要があります。

• TURN サーバは帯域幅要求をサポートしていません。 トラバーサルゾーンの帯域幅制限は適用されません。

• Expressway-E TURN サーバは、TCP および UDP 経由の TURN メディアをサポートします。 サポートされているプロトコルの構成は、CLI コマンド xConfiguration Traversal Server TURN ProtocolMode を通じてのみ可能です。

• Expressway-E TURN サーバは、TCP 経由の UDP リレーをサポートします。

STUN パケットが内部インターフェース経由で送信されることがある

Expressway は、外部 LAN IP アドレスをパケットの送信元アドレスとして使用し、外部 LAN インターフェイスを介して受信した STUN パケットを常に送信します。 通常、パケットは外部インターフェースから送信されるため、IP アドレスは通常一致します。 ただし、次の場合には、Expressway は STUN パケットを 内部 LAN インターフェイスから送信することに注意してください。

• TURN クライアントがリレーセッションを使用して、Expressway-E の内部 IP と同じサブネット内のデバイスにメッセージを送信している場合、または

• TURN クライアントがリレー セッションを使用して、Expressway-E の内部ゲートウェイ IP を使用する静的ルートに一致するサブネット内のデバイスにメッセージを送信している場合。

この動作により、IP アドレスが一致していないという印象を与える可能性があります。しかし、実際にはシステムは設計どおりに動作しています。