Liberty リアルタイム通信の構成
リアルタイム通信フィーチャーの構成は server.xml ファイルを更新することで行われます。
このタスクについて
リアルタイム通信に対応したアプリケーションを実行するように Liberty サーバーを構成するには、 rtcomm-1.0 フィーチャーを設定する必要があります。 リアルタイム通信を使用するアプリケーションで機能するように他のいくつかの構成およびオプションも有効にすることができます。
手順
- rtcomm-1.0 フィーチャーを有効にするには、server.xml ファイルの featureManager エレメント内に次のエレメント宣言を追加します。
<featureManager> <feature>rtcomm-1.0</feature> </featureManager>
デフォルト設定を変更したい場合は、Liberty サーバー構成に Rtcomm フィーチャーを追加する必要があります。これを行うには、WDT ツールを使用するか、または手動で、 server.xml ファイルに次の構成行を追加します
デフォルト設定には以下が含まれます。<rtcomm/>
- Rtcomm MQTT ブローカー接続詳細: (ホスト: localhost、ポート: 1883)
- Rtcomm ルート・トピック・パス: /rtcomm/
- SSL は無効です
注: デフォルト設定が機能するためには、Liberty サーバーと同じマシン上に MQTT ブローカーがインストールされ、使用可能にされている必要があります。MQTT ブローカーのデフォルト設定を変更したい場合は、server.xml ファイルを編集して次のようにする必要があります。<rtcomm messageServerHost="<brokerhostname>" messageServerPort="<brokerportname>" />
- Rtcomm トピック・パスを構成します。rtcommTopicPath は、他の Rtcomm トピック名と共に使用されます。このトピック・パスは、同じメッセージ・ブローカーを使用する他の開発者との競合を避けるために、固有の名前空間を提供します。このパスを設定するには、
server.xml ファイルに次の構成行を追加します。
<rtcomm rtcommTopicPath="/rtcomm/"/>
構成した名前とパスをメッセージ・ブローカー・アドレスと一緒に、rtcomm クライアント・ライブラリーに初期化時に渡す必要があります。サーバーはトピック名を作成して、それをトピック・パスに付加します。
注: rtcommTopicPath は、複数の Liberty サーバーが同じ MQTT ブローカーを使用するように構成されている場合は必ず Liberty サーバーごとに固有でなければならず、そうでないと動作は予測できません。 - rtcommTopicPath の先頭に付加される共有サブスクリプション・パスを構成できます。共有サブスクリプションを使用する場合にメッセージ・ブローカーはこのパスを必要とします。このパスを設定するには、
server.xml ファイルに次の構成行を追加します。
<rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/">
呼び出しキューを使用するときには共有サブスクリプションが構成されている必要があります。呼び出しキューは、 すべてのキュー・リスナーにメッセージを分配するために共有サブスクリプションに依存します。例えば、 複数のヘルプ・デスク・エージェントのすべてが 1 つのキューで listen している場合、一度に 1 つのエージェントに呼び出しを配布するために共有サブスクリプションが使用されます。
注: 共有サブスクリプションのサポートは MQTT ブローカーでの標準ではありません。上記の構成は、 IBM® MessageSight と連携するように rtcomm-1.0 フィーチャーを適切にセットアップする方法を示しています。 共有サブスクリプションの構成に関する、ご使用のブローカーの製品資料を参照してください。 - オプション: Rtcomm フィーチャーを使用するときの追加オプションを構成します。
- Rtcomm フィーチャーと共にバックエンド・サービスを構成する
Rtcomm フィーチャーは、以下を含めて、多数のバックエンド・サービスをサポートします。
- Interactive Connectivity Establishment (ICE) サーバー構成: ピア・メディア・セッションのネゴシエーション時に Rtcomm WebRTC クライアントに送信されて使用される URL を指定します。
- 呼び出しキューのサポート: 共有呼び出しキューをサポートするように Rtcomm を構成できます。また、Rtcomm はユーザーによる共有呼び出しキューの作成を可能にします。 共有呼び出しキューでは、多数のエージェントが 1 つの特定の呼び出しキューをサブスクライブし、カスタマー呼び出しに応答することができます。例えば、 ユーザーはある特定の製品に関するお客様サポートをダイヤル呼び出しできます。多くのエージェントがキューをサブスクライブできますが、 各呼び出しに応答するよう選択されるのは 1 つのエージェントのみです。
- Rtcomm Gateway : 音声ストリームおよびビデオ・ストリームの交換のために、Rtcomm WebRTC エンドポイントとの Session Initiation Protocol (SIP) 接続の機能を追加します。Rtcomm Gateway の構成について詳しくは、『Rtcomm Gateway の構成』を参照してください。
- 代替エンドポイント・ルーティング: ユーザーが代替エンドポイントを介した新規セッションのルーティングを望んでいることを指定します。
- Interactive Connectivity Establishment (ICE) サーバー構成
ICE は、Voice over Internet Protocol (VoIP)、対等通信、ビデオ、インスタント・メッセージ、および他の対話式メディアなどのインターネット・アプリケーション内で NAT (Network Address Translator) が関係するコンピューター・ネットワーキングに使用される技法です。そういったアプリケーションでは、 NAT トラバーサルは、ファイアウォールの背後にインストールされることの多いプライベート・ネットワーク上のホストが関与する通信を利用するための重要なコンポーネントです。
ノード・コントローラーは、 Rtcomm クライアント・ノードに、別のクライアントとのピアツーピア・セッションをセットアップするときにどの ICE サーバーを使用できるのかを通知する手段として ICE サーバー構成を提供します。WebRTC はファイアウォールをトラバースするために ICE サーバーに大きく依存し、 実動デプロイメントでは、エンドポイント間の接続の可能性を最大にするために ICE のサポートを含めることが不可欠です。
ICE サーバー構成は、Rtcomm フィーチャーと関連付けられたコネクター・トピック名にパブリッシュされるサービス照会要求を通してアクセスされます。Rtcomm サービス照会について詳しくは、 プロトコル詳細 GitHub lib.rtcomm.clientjs を参照してください。
さまざまなタイプの ICE サーバーを構成するには、 server.xml ファイルの rtcomm 構成行に以下のプロパティーを追加します。
<rtcomm> <iceServerURL>stun:example1.hostname.com:8880</iceServerURL> <iceServerURL>stun:example2.hostname.com:8881</iceServerURL> </rtcomm>
- サード・パーティー呼び出し制御
サード・パーティー呼び出し制御に関連するメッセージ・フォーマットを定義するすべてのプロトコル詳細が GitHub リポジトリーにあります。 関連するオープン・ソース・コンポーネント lib.rtcomm.node-red および lib.rtcomm.node が、これらのサービスと対話するために使用されます。
- 呼び出しキューのサポート
呼び出しキューは、多くのユーザーが 1 つのキューをサブスクライブでき、別のユーザーがそのキューを呼び出すことができる、ラウンドロビン・スタイルの対話を提供します。 サブスクライブしたユーザーのうちの 1 人のみが呼び出しを受け取ります。このフィーチャーを有効にするには、 キューを定義し、上記のステップ 2 で示されているように共有サブスクリプションを使用可能にします。
呼び出しキューを構成するには、 rtcommTopicPath の先頭に付加される共有サブスクリプション・パスを構成します。 共有サブスクリプションを使用する場合にメッセージ・ブローカーはこのパスを必要とします。server.xml ファイルに次の構成行を追加することによって、サポートされる callQueue を定義できます。<rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/"> <callQueue description="refrigerator" callQueueID="callQueueID2" timeout="500s"></callQueue> </rtcomm>
ユーザーは、必要に応じていくつでも、固有の呼び出しキューを作成できます。構成されると、共有サブスクリプション・パス、rtcomm トピック・パス、およびトピック名を合わせたもの ("$SharedSubscription/rtcomm//rtcomm/callQueue") が、 サーバーからの呼び出し要求を受け取るエージェントによってサブスクライブされます。
各キューに使用可能な構成項目は次のとおりです。
- description の構成: この呼び出しキュー・インスタンスについての文章での説明を指定します。文章でのこの説明は、サービス照会応答に入れて返され、これを使用することでクライアントはキューについて理解しやすくなります。
- callQueueID の構成: 呼び出しキューのトピック名に関連付けられているエンドポイント ID であり、呼び出し元が特定のキューへの呼び出しに使用する宛先エンドポイント ID です。
- timeout の構成: キュー内で待機している呼び出しを終了させるまでの待機秒数。
- 代替エンドポイント・ルーティング
- ユーザーが代替エンドポイントを介した新規セッションのルーティングを望んでいることを指定します。このオプションを使用することによって、alternateEndpointRouting トピック名 (例えば /rtcomm/alternateEndpointRouting) をサブスクライブでき、新しいセッションを適切なエンドポイントにルーティングできます。この機能を有効にするには、
server.xml ファイルに次の構成行を追加します。
<rtcomm alternateEndpointRoutingEnabled="true"/>
- Rtcomm のための SSL 構成
- Rtcomm フィーチャーと MQTT ブローカーとの間で SSL を使用するように環境が構成されていることを確認してください。
- SSL reference は、SSL 対応 MQTT ブローカーに接続するために使用される SSL 構成の ID です。
注: Rtcomm フィーチャーが SSL を使用するためには、SSL フィーチャーが有効になっている必要があります。SSL フィーチャーを有効にするには、 server.xml ファイルに次の構成を追加します。<rtcomm sslEnabled="true" sslRef="mySSLConfig" />
sslRef 構成属性について詳しくは、『Liberty: SSL 構成の属性』を参照してください。

ファイル名: twlp_config_rtcomm.html