デュアル ドメインを使用した Expressway 経由の CMS を使用したプロキシ WebRTC の設定
内容
概要
このドキュメントでは、異なる内部ドメインと外部ドメインを持つExpresswayを介したCisco Meeting Server(CMS)のプロキシWebリアルタイム通信(webRTC)の設定例について説明します。
前提条件
要件
次の項目に関する知識があることを推奨しています。
- シングル連結展開の CMS バージョン 2.1.4 以上
- Expressway-C および Expressway-E バージョン X8.9.2 以上
- CMS の callbridge と webbridge の設定
- Expresswayペアで有効なモバイルアクセス(MRA)とリモートアクセス(MRA)
- Expressway-Eに追加されたリレーNAT(TURN)オプションキーを使用したトラバーサル
- webbridge URLの外部解解可能ドメインネームサーバ(DNS)レコード、外部ドメイン用
- 外部から内部ドメインに入る CMS IP アドレス用の内部解決可能な DNS レコード
- 内部および外部ドメイン用にCMSで構成されたExtensible Messaging and Presence Protocol(XMPP)マルチドメイン
- [Firewall] で TCP ポート 443 をパブリック インターネットからの入力と Expressway-E のパブリック IP アドレスへの出力に開放
- [Firewall] で TCP および UDP ポート 3478 をパブリック インターネットからの入力と Expressway-E のパブリック IP アドレスへの出力に開放
- [Firewall] で UDP ポート範囲 24000 ～ 29999 を Expressway-E のパブリック IP アドレスからの入出力に開放
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- シングル連結展開の CMS バージョン 2.2.1
- Expressway-CおよびExpressway-E(デュアルネットワークインターフェイスカード(NIC)およびスタティックネットワークアドレス変換(NAT)ソフトウェアバージョンX8.9.2)
- Postman
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
設定
ネットワーク図
技術情報
| 内部ドメイン |
cms.octavio.local |
| 外部ドメイン |
octavio.com |
| CMS IP アドレス |
172.16.85.180 |
| Expressway-C IP アドレス |
172.16.85.167 |
| Expressway-E LAN1 IP アドレス（内部） |
172.16.85.168 |
| Expressway-E LAN2 IP アドレス（外部） |
192.168.245.61 |
| スタティック NAT IP アドレス |
10.88.246.156 |
DNS 設定
内部 DNS 設定
外部 DNS 設定
図に示すように、外部DNSには、Expressway-EのスタティックNAT IPアドレスに解決されるwebbridge URLが必要です。
CMS、callbridge、webbridge、XMPP 設定
ステップ1:callbridgeライセンスをアクティブにする必要があります。次の画像には有効な callbridge ライセンスが表示されています。
ライセンスの詳細は次を参照してください。
ステップ2：図に示すように、MMPを使用してcallbridge、webbridge、およびXMPPを有効にします。
有効にする手順の詳細は、次のリンクを参照してください。
証明書の作成手順の詳細は、次のリンクを参照してください。
ステップ3:[Configuration] > [General]でCMS Webページに移動し、図に示すようにWebブリッジの内部URLと外部URLを設定します。
図に示すように、CMSに設定されたスペースの例。
図に示すように、着信コール処理に設定されたドメインの例を示します。
TURN 設定
ステップ1:TURNはPostmanを介してAPIで設定する必要があります。このコマンドはすべての設定で使用します。
https://: /api/v1/turnServers
ステップ2: POSTメソッドを使用し、TURNサーバのパラメータを表示するか、TURNサーバのパラメータを編集するか、Bodyに移動します。TURNサーバに設定されているパラメータは、図に示すとおりです。
ステップ3:GETメソッドを実行してサーバIDをコピーし、TURNサーバ設定のステータスを確認します。コピーする必要があるIDは図に示すとおりです。
ステップ4:APIコマンドの最後にあるIDをコピーし、GETメソッドを使用して、図に示すようにTURNサーバ情報を表示します。
ステップ 5：[send] をクリックしてサーバのステータスを取得します。図に示すように、正常な設定の例です。
Expressway-C および E の設定
ステップ1:expressway-Cには内部ドメイン(octavio.local)が、Expressway-Eには外部ドメイン(octavio.com)が設定されている必要があります。
ステップ2：図に示すように、Expressway CとEの両方でMRAを有効にする必要があります。
ステップ3：図に示すように、Expressway-CとEの間にユニファイドコミュニケーショントラバーサルゾーンを作成します。
Expressway-Cの設定
ステップ1：図に示すように、Expressway-Cで内部ドメインと外部ドメインを設定します。
ステップ 2：Cisco Meeting 設定を有効にします。[Configuration] > [Unified Communications] > [Cisco Meeting Server] の順に開きます。図に示すように、[ゲストアカウントクライアントURI]フィールドに外部webbridge URLを設定します。
図に示すように、Expressway-Cのセキュアシェル(SSH)トンネルは、数秒後にアクティブになる必要があります。
Expressway-E 上の設定
ステップ1：図に示すように、expressway-EにはTURNライセンスが必要です。
ステップ2：図に示すように、Expressway-Eに外部ドメインを設定する必要があります。
ステップ3：図に示すように、TURNサーバとUnified Communicationトラバーサルゾーンのユーザーを作成します。
ステップ4：図に示すように、ユニファイドコミュニケーショントラバーサルゾーンを作成します。
ステップ5:TURNサーバを設定します。図に示すように、[Configuration] > [Traversal] > [TURN]に移動します。
Turnが起動すると、図に示すようにステータスがActiveと表示されます。
ステップ6:[System] > [Administration]に移動します。webRTCクライアントはポート443へのアクセスを要求します。このため、Expressway-Eの管理ポートを別のポートに変更する必要があります。この例では、図のように445に変更します。
ステップ 7：Expressway-E の証明書を作成：図に示すように、webbridge URLをサーバ証明書のSANとして追加する必要があります。
確認
ここでは、設定が正常に機能しているかどうかを確認します。
ステップ1：サポートされているWebブラウザを選択し、外部webbridge URLを入力します。次の画面が図のように表示されている必要があります。
ステップ2:[Join call]を選択し、図に示すように、前に設定したスペースIDを入力します。
ステップ 3：[Continue] をクリックして名前を入力します。このとき、参加するスペース名が表示されていることを確認します。この例では Proxy webRTC がスペース名です。図に示すように[Join call]をクリックします。
ステップ4：別のデバイスに参加します。図に示すように、会議に接続された両方のデバイスが表示されている必要があります。
トラブルシュート
ここでは、設定のトラブルシューティングに使用できる情報を示します。
[Join call] ボタンが表示されない
webbridgeページを開くとJoin callボタンが表示されず、図に示すようにCMS Webページに入力すると2番目の図に示すエラーが表示されます。
この問題は、webbridgeがコールブリッジと正しく通信しない場合に発生します。
解決方法
- CMS 管理 Web ページで webbridge URL が正しく設定されているかを確認します。[Configuration] > [General] の順に開いて確認します。
- webbridgeとcallbridgeは互いを信頼する必要があります。図に示すように、信頼バンドルがwebbridge設定に追加されていることを確認します。
WebRTCページに「Bad Request」と表示される
解決方法
- Expressway-Cで正しいゲストアカウントクライアントURIが設定されていることを確認します。この目的で、[Configuration] > [Unified Communication] > [Cisco Meeting Server]に移動します。
[Guest account client URI] に内部 URL が設定されていると、Expressway-C は DNS サーバで作成されたレコードに基づいて解決させますが、Web ブラウザで「Bad Request」エラー メッセージがトリガーされる可能性があります。この例では、図に示すように、エラーを表示するために内部URLが設定されています。
WebRTC クライアントに非セキュア接続が表示される
解決方法
- 証明書が自己署名であるため、サーバが送信元を信頼していない状態です。Expressway-E の証明書をサポートされているサード パーティ認証局の証明書に変更します。
- 図に示すように、Expressway-Eサーバ証明書で外部webbridge URLがSANとして追加されていることを確認します。
WebRTCクライアントが接続しても接続されず、タイムアウトして切断される
Expressway-E または API で CMS に設定した TURN サーバのユーザ名またはパスワードに誤りがあります。ログには、図に示すエラーが含まれています。
エラーはパケット キャプチャでも確認することができます。webRTC クライアントを実行する PC で Wireshark を実行します。パケット キャプチャができたら、パケットを「STUN」でフィルタ処理します。図に示されているエラーが表示されている必要があります。
PCがAllocate Requestを送信し、Expressway NATアドレスが「Integrity check failure」メッセージで応答します。
解決方法
エラーを修正するには、ユーザ名とパスワードを確認します。これらは、図に示すように、TURNサーバパラメータで正しく設定されている必要があります。
フィードバック