

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# コンタクトコントロールパネル (CCP) で使用される WebRTC の仕組み
<a name="ccp-leverages-webrtc"></a>

この上級者向けのトピックは、コンタクトコントロールパネル (CCP) が音声通話をどのように提供するかに関心がある IT 管理者を対象としています。また、ネットワークの詳細情報についてもいくつか紹介します。

CCP では、コンタクトセンターのエージェントと顧客の間のリアルタイムの通信を実現するために、基盤となるテクノロジーとして WebRTC を使用します。これにより、エージェントはウェブブラウザから直接、着信および発信通話とビデオ会議を管理できます。

**Topics**
+ [WebRTC とは](#whatis-webrtc)
+ [用語](#ccp-leverages-webrtc-terminology)
+ [WebRTC の仕組み](#how-webrtc-works)
+ [STUN、TURN、および ICE の連携の仕組み](#how-stun-turn-ice-works)
+ [ベストプラクティス](#webrtc-ccp-bp)

## WebRTC とは
<a name="whatis-webrtc"></a>

WebRTC は、シンプルな API を使用してブラウザやモバイルアプリケーションでリアルタイム通信 (RTC) を実現するための、オープンソースのテクノロジー仕様です。

接続されたピア間のリアルタイムのデータ交換にピアリング手法を使用し、人と人との対話に必要な低レイテンシーのメディアストリーミングを提供します。

WebRTC 仕様には、ピアツーピア接続を確立するための一連の IETF プロトコル ([Interactive Connectivity Establishment](https://www.ietf.org/rfc/rfc5245.txt)、[Traversal Using Relay around NAT (TURN)](https://datatracker.ietf.org/doc/html/rfc5766)、および [Session Traversal Utilities for NAT (STUN)](https://www.ietf.org/rfc/rfc5389.txt) など) が含まれており、さらに、信頼性の高い安全なリアルタイムのメディアおよびデータストリーミングのためのプロトコル仕様も用意されています。

Amazon Connect では WebRTC が使用されるため、リアルタイム通信のための複雑なインフラストラクチャを構築して維持する必要がありません。これにより、Amazon Connect を通じてオムニチャネルのカスタマーエンゲージメントソリューションを迅速にデプロイできると同時に、WebRTC が提供する低レイテンシーで高品質のメディアストリーミングと、安全なピアツーピア接続を利用できます。

## 用語
<a name="ccp-leverages-webrtc-terminology"></a>

Session Traversal Utilities for NAT (STUN)  
パブリックアドレスを検出し、ピアとの直接接続を妨げるルーターの制限を判別するために使用されるプロトコル。  
STUN エンドポイントを管理するコンポーネントです。このエンドポイントは、アプリケーションが NAT またはファイアウォールの背後に配置されているときにパブリック IP アドレスを検出できるようにします。

Traversal Using Relays around NAT (TURN)  
TURN サーバーとの接続を開き、そのサーバーを介してすべての情報を中継することで、対称 NAT 制限を回避するために使用されるサーバー。  
TURN エンドポイントを管理するコンポーネントです。このエンドポイントは、アプリケーションがメディアのピアツーピアストリーミングを実行できないときに、クラウドを使用したメディアリレーを可能にします。

Session Description Protocol (SDP)  
データの転送後に両方のピアが互いに理解できるように、接続のマルチメディアコンテンツの解像度、フォーマット、コーデック、暗号化などの情報を記述するための標準。

SDP オファー  
セッションを作成または変更するためにセッションの説明を生成する、エージェントによって送信される SDP メッセージ。これは、希望するメディアコミュニケーションの局面を記述します。

SDP アンサー  
オファー側から受信したオファーに応答してアンサー側が送信する SDP メッセージ。アンサーは、受け入れられる局面を示します。例えば、オファー内のすべてのオーディオストリームとビデオストリームが受け入れられるかどうかなどです。

Interactive Connectivity Establishment (ICE)  
ウェブブラウザがピアと接続できるようにするフレームワーク。

ICE 候補  
送信ピアが通信に使用できる方式。

ピア  
WebRTC を使用したリアルタイムの双方向通信に対応できるように設定されたデバイスまたはアプリケーション (モバイルアプリケーションやウェブアプリケーションなど)。

通知中  
シグナリングコンポーネントは、アプリケーションが相互に安全に接続してピアツーピアのライブメディアストリーミングを行えるようにする WebRTC シグナリングエンドポイントを管理します。

## WebRTC の仕組み
<a name="how-webrtc-works"></a>

WebRTC は、ブラウザ用の JavaScript Session Establishment Protocol (JSEP) や、WebSockets/XMPP 上に構築されたカスタムプロトコルなどの、シグナリングプロトコルを使用して、通信セッションを開始および管理します。また、音声およびビデオデータのエンコード/デコードのためのコーデック、メディアストリームを暗号化してプライバシーを確保するための Secure Real-Time Transport Protocol (SRTP) を採用しており、ICE、STUN、TURN プロトコルを使用して NAT ゲートウェイやファイアウォールを越えたピアツーピア接続を確立します。

## STUN、TURN、および ICE の連携の仕組み
<a name="how-stun-turn-ice-works"></a>

エージェント CCP (コンタクトコントロールパネル) をピア A、Amazon Connect をピア B として、WebRTC を使用して双方向メディアストリーム (音声通話など) を確立するシナリオを考えてみましょう。

エージェント CCP が Amazon Connect との接続を確立しようとすると、以下の状況が発生します。

1. エージェント CCP が、目的のセッションに関する情報 (使用するコーデック、セッションか音声かビデオかなど) を含む SDP オファーを生成します。オファーには、ICE 候補のリストも含まれます。これは、Amazon Connect がエージェント CCP への接続に使用できる IP/ポートのペアです。

1. ICE 候補を収集するため、CCP は STUN サーバーに一連のリクエストを行います。STUN サーバーは、リクエストを発信したパブリック IP アドレスとポートのペアを返します。さらにエージェント CCP は、Amazon Connect の TURN サービスに対する TURN チャネルを作成して、メディアリレーアドレスを取得します。このリレーアドレスは、エージェント CCP と Amazon Connect の他のメディアサービスの間でパケットを転送できる IP/ポートのペアです。エージェント CCP は、IP/ポートの各ペアを ICE 候補のリストに追加し、SDP オファーを WebSocket 経由でシグナリングチャネルを介して Amazon Connect に送信します。

1. Amazon Connect が、同じプロセスに従って SDP 回答を生成します。ICE 候補を収集し、SDP 回答とともに WebSocket 経由でエージェント CCP に送信します。SDP を交換したら、エージェント CCP と Amazon Connect は一連の接続チェックを実行します。どちらも、相手の SDP から IP/ポートのペアの候補を取得し、STUN リクエストを送信します。レスポンスを受信すると、その IP/ポートのペアは有効な ICE 候補ペアとしてマークされます。

1.  すべての IP/ポートのペアの接続チェックが完了すると、エージェント CCP と Amazon Connect は、メディアストリームに使用する有効なペア 1 つをネゴシエートして決定します。

次の図は、CCP と Amazon Connect の間の WebRTC を使用した通信を示しています。

![\[CCP と Amazon Connect の間の WebRTC を使用した通信フロー。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/webrtc-diagram.png)


## ベストプラクティス
<a name="webrtc-ccp-bp"></a>
+ 最も信頼性が高く最高の音声エクスペリエンスを実現するために、エージェントワークステーションと AWS の間のメディアトラフィックが、VPN やその他のネットワークアクセラレーターホップを経由せずに直接交換されるようにすることを強くお勧めします。
+ WebRTC 接続を正常に確立してエラー動作を軽減するために、必ずポート 3478 (送信/受信) での受信 UDP トラフィックを許可リストに登録します。詳細については、「[オプション 1 (推奨): Amazon EC2 および CloudFront の IP 範囲の要件をドメイン許可リストに置き換える](ccp-networking.md#option1)」を参照してください。表で、`TurnNlb-*.elb.region.amazonaws.com` の行を参照してください。
+ [オプション 2 (推奨しません): IP アドレスの範囲を許可する](ccp-networking.md#option2) を使用している場合は、エラー動作を軽減するために以下をお勧めします。
  + 組織が許可リストに登録した Amazon Connect の IP 範囲をモニタリングします。
  + IP 範囲内の変更がモニタリングされるようにします。
  + リストに新たに追加する場合は、必ず、送信/受信トラフィック用の 3478 (UDP) ポートとプロトコルが許可リストに含まれていることを確認します。
+ 本番環境に移行する前に、以下を行います。
  + [Amazon Connect エンドポイント接続テストツール](check-connectivity-tool.md)を使用して WebRTC 接続をテストします。このツールは、エージェントステーションから Amazon Connect WebRTC メディアエンドポイントにアクセスできるかどうかを確認するのに役立ちます。
  + ファイアウォールの更新、エッジルーター、VPN など、[ネットワーク環境](network-ts.md#investigate-ndc)に加えた変更やオンプレミスのネットワークアーキテクチャをテストして追跡します。
+ ステートレスファイアウォールを使用している場合は、「[ステートレスファイアウォール](ccp-networking.md#stateless-firewalls)」の説明に従って、一時ポート範囲を許可リストに追加していることを確認します。