企業トレーニングのウェビナー、会議、公開会議、集会、SIPプロトコルを使用した既存のサービスおよびソリューションを使用する場合。 ただし、このようなサービスには、原則として、インターネットでの大量放送（ブロードキャスト）を目的としたソリューションがありません。 Zoom.us、InterCall、Twilio、Vidyo、iMeetなどの既存のサービス、および他のソフトウェアとハードウェアのソリューションおよび他のメーカーの製品は、SIPプロトコルを使用して開催された会議をインターネットでの大量放送に変換する機能を提供しません。
上の図に示すように、選択したソリューション（ソフトウェア製品とサービスの組み合わせ）を選択することで、最小限の労力でイベントのオーディエンスを拡大できるようにするという目標を設定しました。
以下では、2つのストリーミングビデオサーバーであるAdobe Media ServerとWowza Streaming Engine、Twilio、Zoom.us、Vidyo、Lifesize、Blue Jeans、iMeet、CounterPath Bria 4ソフトフォン、Flashphoner Web Call Server 4プラットフォーム間のさまざまな組み合わせで可能な統合オプションについて検討します。
ナビゲーション
統合プラットフォームの基本要件
検証実験のスキーム。
実験の条件。
zoom.usサービスとの統合。
Web Call Serverの起動と設定4。
Web Call Serverを介した接続の開始4。
Web Call Server 4を介して確立された接続を管理します。
Zoom.usから複数の接続をブロードキャストします。
統合で起こりうる問題の分析。
Twilioサービスとの統合。
Office Web Call Server。
OpenSIPSとの統合。
Vidyoとの統合。
Blue Jeansサービスとの統合。
Lifesizeとの統合。
iMeetとの統合。
最終的な結論。
使用されるリソース。
検証実験のスキーム。
実験の条件。
zoom.usサービスとの統合。
Web Call Serverの起動と設定4。
Web Call Serverを介した接続の開始4。
Web Call Server 4を介して確立された接続を管理します。
Zoom.usから複数の接続をブロードキャストします。
統合で起こりうる問題の分析。
Twilioサービスとの統合。
Office Web Call Server。
OpenSIPSとの統合。
Vidyoとの統合。
Blue Jeansサービスとの統合。
Lifesizeとの統合。
iMeetとの統合。
最終的な結論。
使用されるリソース。
テストの候補が選択された方法
さまざまなサービスとソフトウェア製品の相互互換性とインターネットでの大量放送の可能性をテストすることを決定したため、いくつかの基準に従ってサービスと製品を選択しました。
他のサービスとソフトウェアを統合するサーバーの基本要件：
- さまざまな統合サービスおよびソフトウェア製品の柔軟な設定メカニズム。
- 詳細なドキュメントの入手可能性;
- 製造元からの技術サポートの利用可能性;
- 管理の容易さ。
サービスを選択する際の主な基準は次のとおりです。a）サービスはソフトウェアを使用するためのテスト期間を提供できること。 b）サービスは、参加者をSIP経由で接続するためのサポートがあることを宣言または暗示する必要があります。 zoom.usサービスとBriaでは、このルールにいくつかの例外を設けました。これは、このソフトフォンとその機能および使用機能に精通しているためです。zoom.usサービスは、優れた機能が宣言されたかなり新しいスタートアップです。 （このサービスのSIP接続が有料であっても）テストすることにしました。
策定された選択基準、さまざまな統合ソフトウェアでの経験、およびこのソフトウェアを使用する利便性に基づいて、実験にWeb Call Server 4を使用することにしましたが、他のソフトウェアも可能です。
テスト実験計画
以下の図に、ソース（右）とコンテンツ受信者（左）の間の相互作用の最も一般的なオプションの1つを示します。
統合プラットフォームを介して相互作用を整理するためのさまざまなオプションをチェックするとき、実験のニーズに応じて示されたスキームを再配置したことに注意してください。
実験で使用したストリーミングビデオサーバー：
- Wowzaストリーミングエンジン
- Adobe Media Server
統合プラットフォーム：
- Flashphoner Web Call Server 4
- RESTコンソール（Google Chrome）
ブロードキャストソース：
- CounterPath Bria 4
- Twilio.comサービス
- サービスZoom.us
- iMeetサービス
- Vidyoサービス
- ブルージーンズサービス
- 等身大サービス
ブロードキャスト（またはコンテンツ）を表示するためのプログラム：
- フラッシュプレーヤー
RTMPストリームをサーバーに送信するプログラム：
- Adobe Flash Media Live Encoder 3.2
実験の条件
実験の前提条件は、上記のソフトウェア製品が正しくインストールおよび構成されていることです。
以下のスクリーンショットは、ローカルクライアント（CDNプラットフォームが起動されたローカルネットワーク外）にインストールされたAdobe Flash Media Live Encoderのセットアップを示しています。
Adobe Flash Media Live Encoderからのブロードキャストを、ストリーミングビデオサーバーを介したオーディオ/ビデオストリームの検証ソースとして使用しました。 結果のストリーム（ストリーミングビデオサーバーの後）は、Flash Playerを使用して確認されました（下のスクリーンショットを参照）。
ソースとレシーバー（プレーヤー）の両方でストリーム設定（IPアドレス、ポート、ストリーム名）を慎重に確認することが不可欠です。
翻訳検証スキーム（ストリーミングビデオサーバーの健全性）を以下に示します。
オーディオ/ビデオストリームがRTMPサーバーに到達していることを確認した後、プレーヤーを介してテストに直接アクセスできます。
また、TwilioサービスでWeb Call Serverをテストする際、Web Call Serverがインターネットにアクセスするためにサービスプロバイダーによって割り当てられるパブリックIPアドレスを確立し、このアドレスをSIPドメイン設定に登録する必要があります。 パブリックIPアドレスに対しても同じ操作を行う必要があります。パブリックIPアドレスは、Bria（ローカルコンピューターにインストールされている）でTwilioサービスをテストするために使用されます。
zoom.usサービスとの統合
遠隔学習への関心の高まりとリアルタイムでのオーディオ/ビデオ情報の空間分散交換により、必要な機能を提供するさまざまなサービスが人気を集めています。 これらのサービスの1つがzoom.usです。
このサービスを使用したテストの構成は次のとおりです。
まず、アカウントを設定し、手順に従って仮想教室を「開始」する必要があります（スクリーンショットを参照）。
開始後、サービスによって提供されるソフトウェアがローカルコンピューターで起動され、マイクからの音声とコンピューターのカメラからのビデオがキャプチャされます。
各会議には一意の9桁のIDが割り当てられ、ブロードキャストに使用されるサービスのIPアドレスとともに、サードパーティの参加者を会議に招待できることがわかります。 次のスクリーンショットに一連のアクションを示します。
最終的に、zoom.usが提供するIPアドレスと会議IDを使用して、「会議に参加」するようにWeb Call Server 4とビューアを構成できます。
Web Call Server 4の起動と構成
Web Call Server 4は異なるコンテンツソースとストリーミングサーバー間の統合ツールであるという事実にもかかわらず、各会議（または他のソース）は、標準SIP、RTMPプロトコルを実装するための個別の設定、機能、および文書化されていない要件を持つことができます。
特定のケースでは、両方のストリーミングサーバーが同じデバイスにインストールされているため、最初のステップは、サーバー（AMSまたはWSE）の1つのみが同時に動作していることを確認することです-それ以外の場合（ソフトウェアごとに個別のデバイスがある場合）、次の操作は不要です
以下に示すように、サーバーのストリーミングを強制的に停止する必要がありました。
コンソール
[root @ wowza ams]＃./amsmgr server ams stop
サーバー：amsコマンド：停止
NPTL 2.12
Adobe Media Serverの停止（/ var / log / messagesを確認してください）
サーバーがシャットダウンしました...
[root @ wowza ams]＃service WowzaStreamingEngine start
WowzaStreamingEngine：開始しています...
この特定の例では、AMSが停止し（ポート1936で動作することを事前に知っています）、Wowza Streaming Engineはアドレス1935（アドレス45.101.139.105）で動作します。
次に、Web Call Server 4サーバーの構成が使用されるコンテンツソース（この例ではzoom.us）のパラメーターと一致することを確認する必要があります。たとえば、sshを介して、Web Call Server 4がデプロイされているサーバーにアクセスし、。/ confディレクトリでファイルを見つけることができます以下のスクリーンショットに示すように、構成：
ファイル自体で、スクリーンショットに示されているように、コーデックパラメーターとその他の多くのパラメーターを変更する必要があります（この場合、他のサービスに適用できるパラメーターは単に「コメント化」できます）。
構成ファイルに新しいパラメーターを保存した後、Web Call Server 4を再起動します（以下を参照）。
コンソール
[root @ SF1 conf]＃service webcallserver stop
FlashphonerWebCallServer：停止[OK]
[root @ SF1 conf]＃service webcallserver start
FlashphonerWebCallServer：開始[OK]
上記のすべてのアクションの結果、ストリーミングビデオサーバーとWeb Call Server 4が正しく機能することが保証され、Web Call Server 4とブロードキャストソースの直接制御に進むことができます。
Web Call Server 4を介した接続
Web Call Server 4を正しくインストールして構成したら、一般に、このソフトウェア製品はコンテンツソースとストリーミングサーバーの間の仲介として機能することを覚えておく必要があります。 一般的な場合、メディエーションは、コンテンツソースへのSIPコールの開始、コンテンツソースからの応答の受信、コンテンツ自体の受信、およびこの受信したコンテンツのストリーミングサーバーへのブロードキャストで構成されます。
Web Call Server自体には管理ツールが必要であり、その実装はREST / JSON APIコマンドによって編成されています。 このような管理メカニズムは、既存のソフトウェア製品に統合でき、Web Call Serverの自動管理を提供します。
特定のケースでは、パラメーター付きのリクエストがWeb Call Serverに送信されるRESTコンソールを使用します。WebCall Serverは、CDNと統合する必要があるコンテンツソースに依存します。
たとえば、zoom.usで開催された会議に参加するには、次のリクエストを送信する必要があります（Google Chrome RESTコンソールを使用して行います）。
RESTコンソール
{
「CallId」：「Xq2tlLcX89tTjaji」、＃任意の呼び出し識別子
「Callee」：「10000」、＃発信者名（ランダムに選択）
"RtmpUrl"： "rtmp：//45.101.139.105：1935 / live"、＃ブロードキャストアドレス（プラットフォームCDN）
"RtmpStream"： "lifestream1"、＃ストリーミングされるストリームの名前
"HasAudio"： "true"、＃オーディオコンテンツの属性（yes / no）
"HasVideo"： "true"、＃ビデオコンテンツの属性（yes / no）
「接続」：＃接続パラメーター
{
「SipLogin」：「10000」、＃ログイン
「SipPassword」：「10000000」、＃パスワード
"SipAuthenticationName"： "10000"、＃認証の名前
「SipDomain」：「162.255.36.11」、＃会議のIPアドレス（zoom.usにより提供）
「SipPort」：「5060」、＃SIPブロードキャストが行われるポート
「SipRegisterRequired」：「false」、＃ドメイン登録属性
「AppKey」：「callApp」
}
}
上記のパラメーターを含むリクエストは、以下のスクリーンショットに示すように、特別なWeb Call Server URIに送信されます。
Web Call Server 4からの要求が完了すると、WebCallServerはzoom.us（この場合、Web Call Server 4が「リスナー」の1つとして機能する）によって開催された会議に接続され、同時にWeb Call Server 4が受信した応答（zoom.usサービスのコンテンツ） -Web Call Server 4は、ストリーミングビデオサーバーにさらにリダイレクトされます（下のスクリーンショットを参照）。
Web Call Serverを介して確立された接続を管理する
この特定の場合、zoom.usサービスでは、「会議」の特定の識別子（この場合は311 705 123）をzoom.usサーバーに送信して、特定の「会議」に追加で接続する必要があります。 1つの方法は、DTMFトーンダイヤル（たとえば、ソフトフォンキーボード上）です。 スクリーンショットに示すように、Web Call Server 4は同じ操作を実行できます。
次のコマンドを使用して、RESTコンソールからこのようなリクエストを送信することもできます。
RESTコンソール
/注：構文1 **********は、zoom.us /を使用する際の実用的なノウハウです。
{
「CallId」：「Xq2tlLcX89tTjaji」、＃前のリクエストと同じID
「タイプ」：「RFC2833」、
"Dtmf"： "1 ********** 311705123＃"＃zoom.usサービスによって提供される一意のID
}
/注：構文1 **********は、zoom.us /を使用する際の実用的なノウハウです。
その結果、以下のスクリーンショットに示すように、特定の「サブスクライバー」が特定の「会議」のブロードキャストに接続されます。 スクリーンショットを見るとわかるように、zoom.usインターフェイスのウィンドウには、Web Call Serverロゴが表示されています。このロゴは、起動された「ラリー」の「リスナー」の1つです。
同時に、Wowza Flash Playerウィンドウで、zoom.usからWeb Call Server 4経由でWowza Streaming Engineサーバーにリダイレクトされたブロードキャストが表示されます（スクリーンショットを参照）。
したがって、RESTコンソールを介してWeb Call Server 4に送信される2つのコマンドにより、zoom.usで会議への参加（「集会」）を開始し、コンテンツ（「画像」およびオーディオストリーム）をWowza Streaming Engineサーバーにリダイレクトして、 CDNネットワーク。
Zoom.usから複数の接続をブロードキャストします
Web Call Server 4は、実際にテストしたzoom.usサービスからの任意の数の接続の変換を提供できます。
これを行うには、以下のスクリーンショットに示すようにBriaアカウントを構成する必要があります。
また、オーディオとビデオに十分なコーデックをインストールする必要があります。
さらに、集会が行われる部屋の一意のIDをダイヤルすると、一般会議への接続が、CDNサーバーを介した共通コンテンツのブロードキャストで行われます。
考えられる統合の問題の分析
Web Call Server 4と他のソフトウェア製品およびサービスとの相互作用の失敗の考えられる原因に関する知識のソースとして、スクリーンショットに示すように、Web Call Server 4がインストールされているサーバー上のログファイルを参照することをお勧めします。
スクリーンショットに示すように、RESTコンソールを介したクエリ実行の結果は、Google Developer Toolsが提供するツールでも表示できます。
Twilioサービスとの統合
Web Call Server 4統合プラットフォームの柔軟性をテストするために、Twilioサービスとの相互作用もテストしました。
実験の構成を図に示します：
TwilioアカウントとSIPドメインのセットアップ
Twilioサービスの使用を開始するには、サービスにアカウントを設定し、ソフトフォンが接続するドメインを作成する必要があります。 これらのアクションのシーケンスを次のスクリーンショットに示します。
ステージ1.ドメインの作成-この例では、flashphoner2
ステージ2-ドメインのアクセスリストの作成とアクセス権の定義
ステップ2.1-ドメインアクセスが許可されるIPアドレスのリストを作成します。
このリストに、加入者デバイス（ソフトフォン）のIPアドレスとWeb Call Server 4のIPアドレスの両方を含めることが重要です。
ステップ2.2 -アクセス権の作成
Twilioサービスでドメインが作成された後、アクセス権とアクセスが許可されるIPアドレスのリストが生成されます-ソフトフォン（この場合はBria 4）の構成を開始できます。
Briaの構成とTwilioドメインへの参加
Briaの設定では、以下のスクリーンショットに示すように、Twilioにアクセスするためのアカウント（アカウント）を作成する必要があります。
Bria設定の同じ場所で、オーディオコーデックの使用を構成する必要があります：G711 aLaw、uLaw、およびH.264ビデオコーデック。
その後、Briaを介してテストコールを行い、Twilioが提供する留守番電話の録音をソフトフォンで聞くことができます。
サービスのドメインが正しく構成されている場合（および留守番電話がBriaで聞こえる場合）、Web Call Serverの制御コマンドの作成を開始できます。
Twilioで使用するためのWeb Call Server構成の変更
Web Call Server 4でTwilioサービスをテストするときは、サーバー設定を変更する必要があります。 このような変更は、flashphoner.properties構成ファイルに対して行われます。
特に、使用されるコーデックのセットと他の多くのパラメーターが変更されています。
構成ファイルの変更内容と変更方法は、統合サーバーの製造元が提供するWeb Call Server 4のドキュメントに記載されています。
Web Call Serverの構成を変更した後、変更を有効にするにはサーバーを再起動する必要があります。
コンソール
[root @ SF1 conf]＃service webcallserver stop
FlashphonerWebCallServer：停止[OK]
[root @ SF1 conf]＃service webcallserver start
FlashphonerWebCallServer：開始[OK]
Webコールサーバー管理
前の実験と同様に、Web Call Serverは、以下に示すように、Google Chrome RESTコンソールを介してRESTコマンドを送信することにより管理されます。
RESTコンソール
{
「CallId」：「Xq2tlLcX89tTjaji」、
「呼び出し先」：「flashphoner2.sip.twilio.com」、
「RtmpUrl」：「rtmp：//45.100.109.105：1936 / live」、
「RtmpStream」：「lifestream1」、
「HasAudio」：「true」、
「HasVideo」：「true」、
「接続」：{
「SipLogin」：「flashphoner2」、
「SipPassword」：「RadK2151312」、
「SipAuthenticationName」：「flashphoner2」、
「SipDomain」：「flashphoner2.sip.twilio.com」、
「SipPort」：「5060」、
「SipRegisterRequired」：「false」、
「AppKey」：「callApp」
}
}
「CallId」：「Xq2tlLcX89tTjaji」、
「呼び出し先」：「flashphoner2.sip.twilio.com」、
「RtmpUrl」：「rtmp：//45.100.109.105：1936 / live」、
「RtmpStream」：「lifestream1」、
「HasAudio」：「true」、
「HasVideo」：「true」、
「接続」：{
「SipLogin」：「flashphoner2」、
「SipPassword」：「RadK2151312」、
「SipAuthenticationName」：「flashphoner2」、
「SipDomain」：「flashphoner2.sip.twilio.com」、
「SipPort」：「5060」、
「SipRegisterRequired」：「false」、
「AppKey」：「callApp」
}
}
要求はWeb Call Serverアドレスに送信されます：http：//107.179.239.129:9091/RESTCall/call。
リクエストの結果として、TwilioサービスのSIPドメインへの呼び出しが生成され、Flash PlayerでTwilioサービスから受信した応答を聞くことができます。または、Twilio留守番電話からメッセージを再生できます。
したがって、TwilioとBria間の統合ソリューションとしてWeb Call Server 4の動作をテストした結果、統合サーバーはTwilioサービスおよびこのサービスに接続されたソフトフォンと対話できると確信しました。
OpenSIPSとの統合
IP-PBXソリューションとの相互作用の可能性をテストするために、IP-PBX OpenSIPSサーバーでテストが実施されました。
テストサイトのレイアウトを以下に示します。
この場合、Briaはサードパーティのサブスクライバーからの呼び出しを受信し、コンテンツで呼び出しに応答する「サービス」として機能します。 この特定のケースでBriaが行動するこの他の役割に関連して、以下のスクリーンショットに示すように設定を変更する必要があります。 特に、IP-PBX OpenSIPSを呼び出すアカウントを作成する必要があります。
前のケースと同様に、Web Call Serverを制御する機能を示すために、リクエストを送信します。
RESTコンソール
{
«callId»:«Xq2tlLcX89tTjaji»,
«callee»:«10050»,
«rtmpUrl»:«rtmp://45.101.139.105:1935/live»,
«rtmpStream»:«lifestream1»,
«hasAudio»:«true»,
«hasVideo»:«true»,
«connection»:{
«sipLogin»:«10051»,
«sipPassword»:«15001»,
«sipAuthenticationName»:«10051»,
«sipDomain»:«87.222.225.52»,
«sipPort»:«5080»,
«sipRegisterRequired»:«false»,
«appKey»:«callApp»
}
}
呼び出しは、OpenSIPSサーバーで作成されたアカウント10051を介して行われ、呼び出されたサブスクライバーの「番号」が「呼び出し先」フィールドに示されることに注意してください。
その結果、Webサブスクライバー4から「サブスクライバー」10050への呼び出しがストリーミングサーバーにリダイレクトされ、その後Flash Playerを介してリッスンされました。
Vidyoとの統合
私たちがテストした別のサービスはVidyo.comです。マスブロードキャストの必要性は、このサービスの各ブロードキャスト（ラリー）の参加者数が限られているため、通常のサービス（Vidyo）を使用して50、100人以上の参加者とイベントを開催する必要がある場合があります。
他のサービスの場合と同様に、最初にサービスへの登録が必要です。
さらに、登録後、ローカルコンピューターにソフトウェアをインストールし、アクティベーション中に取得したデータを入力してサービスに接続する必要があります。
データを入力すると、サービスへの接続が確立され、会議（仮想会議の部屋）を作成できるようになります。スクリーンショットは、サービスに登録および接続されたそれぞれに一意の内線番号（Extension）が提供されることを示しています。
他の参加者を会議（会議室）に接続するには、電子メールなどで他の参加者に招待状を送信する必要があります。
プログラムウィンドウで対応するアイコンをクリックすると、プログラム内に電子メールを処理するためのドラフトメッセージが作成され、接続データが表示され、会議の他の潜在的な参加者に報告する必要があります。
そのような手紙のテキストを以下に示します。
Let's meet via Vidyo!
— To join from your desktop or mobile device: Click join.vidyo.com/flex.html?roomdirect.html&key=1sQAgMIbOVihE3SFKKjl47oryI
— To join from your H.323/SIP video conferencing system inside the US: 75.98.89.60 and 1501005148 and PIN (If required)
— To join from your H.323/SIP video conferencing system outside the US: 31.186.235.56 and 1501005148 and PIN (If required)
— To join from telephone: (800) 916-5971, Conference ID 1501005148, and PIN (If required)
NOTE: Any video, audio and/or materials viewed during this conference may be recorded.
Need help getting started? Check out the Vidyo Knowledge Center at www.vidyo.com/knowledge-center
Vidyoサービスから受信したデータの操作性を確認するために、サービスが提供するデータに基づいてBriaソフトフォンにアカウントを作成しました。
Briaでアカウントを作成するとき、ユーザー名とパスワードは任意に選択でき、接続されるIPアドレスと（将来）会議室に接続するためにダイヤルされる番号のみが重要であるという事実から進めました。
ダイヤラがこのサービス専用に作成されるように、Vidyoサービス用に作成されたアカウントのみをBriaに含める必要があることに注意してください。
番号1501005148をダイヤルした後、Briaキーボードは会議が開催される仮想「部屋」にダイヤルして接続します。
プログラムウィンドウでは、以下のスクリーンショットに示すように、会議に新しい参加者が現れたことを確認できます。
Briaを介したテストが成功したため、Web Call Server 4とVidyoサービスの統合のテストを開始します。
これを行うには、以下のスクリーンショットに示すように、RESTコンソールでコマンドを作成し、Web Call Server 4にリクエストを送信します。
要求を送信すると、新しい会議参加者がVidyoサービスのWebサイトに表示されます（Web Call Serverコマンドで指定したIDを使用）。
同時に、接続されたサービスからのブロードキャストの可用性を確認するプレーヤーでは、Webカメラからのブロードキャストの代わりとして、ラリーイニシエーターによってサービスに送信された画像を含むウィンドウを見ることができます。
以前は、ストリーミングビデオサーバーを開始するメカニズムについて説明しましたが、このテストではAMSとWSEの両方を使用し、Web Call Serverの設定はzoom.usサービスで指定したとおりに使用しました
ブルージーンズの統合
インターネットで会議を開催するための比較的よく知られたサービスの1つは、ブルージーンズサービスです。このサービスとの統合も確認することにしました。
このサービスは、会議を（ラリー）開催するための非常に簡単なメカニズムも提供します。最初に、以下に示すように、アカウントを登録して作成する必要があります。
このステップの後、同様のサービスの以前の場合と同様に、Blue Jeansサービスによって提供されるソフトウェアをインストールする必要があります。
コンピューターにBlue Jeansソフトウェアをインストールした後、このソフトウェアを使用してさらに手順を実行します。
当然、誰かを会議に接続するには、この会議を整理する必要があります。このため、Blue Jeansソフトウェアでは、このような会議を作成し、作成した後、会議データを潜在的な参加者に送信する必要があります。この場合：
- IPアドレス（ダイヤルIP）
- ミーティングID
- 検証コード（パスコード）
招待する2番目の参加者が同じBlue Jeansソフトウェアを使用している場合、Blue Jeansサービスは特別なウィンドウにコードを入力することを提案し（「ペアリングコード」）、ソフトウェアを「並列化」できます。ただし、このような機能はテストの目的には使用されず、サービスが提供する会議IDとパスコードを使用しました。
会議が開催されている仮想「部屋」に接続するためのデータを受信した後、私たちは、以前のように、Briaソフトフォンでサービスの動作を確認することにしました。
これを行うには、以下に示すようにBriaでアカウントを作成します。
ルームを作成するときに、ダイヤルにIPアドレス（上記参照）またはドメイン名bjn.vc.を直接使用することが提案されているため、Blue Jeansコミュニティからドメインのデータを収集したことに注意してください。
SIPを使用して接続するためにsip.bjc.vc表記を使用する必要があるという事実は、以下に示すように、コミュニティのメッセージで説明されています。
Briaでアカウントを作成した後、キーボードでラリーIDを入力し、写真（この場合はManyCamで以前に記録したビデオクリップ）をラリーにブロードキャストし、以下に示すようにBriaでラリーデータをブロードキャストしました。
さらに、Blue JeansとWeb Call Server 4の統合機能を確認し、RESTコンソールを使用してWeb Call Server 4のアドレスに次のリクエストを送信しました。http：//107.179.239.120:9091/RESTCall/call：
RESTコンソール
{
«callId»:«100501Cxbsf»,
«callee»:«5322844144»,
«rtmpUrl»:«rtmp://45.101.139.105:1935/live»,
«rtmpStream»:«livestream1»,
«hasAudio»:«true»,
«hasVideo»:«true»,
«connection»:{
«sipLogin»:«100501»,
«sipPassword»:«9354»,
«sipAuthenticationName»:«100501»,
«sipDomain»:«sip.bjn.vc»,
«sipPort»:«5060»,
«sipRegisterRequired»:«false»,
«appKey»:«callApp»
}
}
リクエストでは、ラリーIDが呼び出し先フィールドとして使用され、コミュニティから取得されたデータがsipDomain、つまりsip.bjc.vcとして使用されることに注意
する必要があります。 、2番目のWeb Call Server 4）、以下に示すとおり：
プレーヤーでは、それに応じてローカルコンピューターの「画像」を確認できます（以下を参照）。つまり、ローカルコンピューターで「ブルージーンズ」ソフトウェアが「見る」ものを確認できます。次に、Blue Jeansソフトウェアはこのビデオをサービスに送信します。WebCall Server 4はすでにBlue Jeansサービスから応答を開始して受信し、Flash Playerウィンドウに表示されるストリーミングビデオサーバー（実験ではAMSまたはWSE）にリダイレクトします。 'a。
一般的な印象では、SIP接続に特定のドメインを使用する必要があるという「デフォルト」を除き、Blue Jeansサービスとの一般的なやり取りはシンプルで比較的手間がかからないことが判明しました。
Lifesizeとの統合
テストされた統合とは別の利用可能なサービスは、Lifesizeサービスです。
以前のサービスをご利用のすべてのユーザーと同様に、サイトに登録し、サービスが提供するソフトウェアをダウンロードしてインストールした後、サービスを使用できます。
ローカルコンピューターにソフトウェアをインストールしたら、「いつものように」と言うことができます。会議を作成する必要があります（下のスクリーンショットを参照）。
次のように、各会議について、サードパーティの参加者がダイヤル（アピール）して会議に参加できる連絡先（データ）が提供されます。
Lifesizeサービスが提供するデータをダイヤルに使用し、サービスへの接続の各段階に視覚情報が含まれていることに驚きました（ただし、音声アシスタントは、すべての同様のサービスに共通の機能です）。
Web Call Server 4は、通常どおり、RESTコンソールからコマンドを使用して、提供されたデータに従ってLifesizeサービスとの接続を確立しました（上記を参照）。
サービス自体は、プログラムに接続された参加者のウィンドウを表示します。
そして、参加者の数を示します。
また、応答結果はWeb Call Serverによってストリーミングサーバー（AMSまたはWSE）にブロードキャストされました。
主観的な感情によると、このサービスは通信チャネルの品質をより要求しますが、この観察は何らかの確認された事実ではなく、完全に主観的です。
iMeetとの統合
IMeetサービスは、電話を使用して参加者を接続する機能など、インターネット上で共同イベントを開催するためのさまざまなソリューションを提供します。
このサービスを使用するためにダウンロードしてインストールする必要があるプログラムのインターフェイスは、そのカラフルなデザインと付随する情報（時間、天気など）が際立っています。
以前と同様に、サービスはデータを提供しますが、以前のものとは異なり、タイプのURIはダイヤルアップアドレスとして提供されます：www.imeet.com/georgeb
以前のサービスと同様に、サードパーティの参加者を会議に招待する可能性があります（電子メールを含む）。また、非常に便利なことに、サービスから潜在的な参加者の電話番号にダイヤルします（つまり、参加者は電話する必要はありませんが、サービスが必要です）呼び出し）。
メール招待状のリンクを使用して、Webブラウザーを使用して会議に参加できました（ソフトウェアをインストールする必要はありません）。
ただし、Briaソフトフォンから集会に到達することはできませんでした。これは、私たちの観点からは、サービスによって次のコメントで説明されています。
「iMeetはSIP / SIMPLEまたはXMPPと直接統合されていませんが、iMeetは各ホストに個人的なオンライン会議室を提供します。そのため、URL（例：www.imeet.com/georgeb）をIM会話に入れることもできますゲストを会議に招待します。iMeet URLをSalesforceプロファイルに保存して、そこから直接iMeetに接続できるようにすることもできます！”（Community.imeet.com/thread/1700）
受け取った推奨事項と次のBria設定を使用すると、ラリーとの接続はまだありません（Domainパラメーターはwww.imeet.com/Vlad439323とwww.imeet.com/Vlad439323の両方に変更されました）。
SIPプロトコルを使用して接続するには、他のソフトウェアとiMeetVRCなど、このサービスで提供されるわずかに異なるタイプのサービスをテストする必要があると思います。
これは、後続のテストで確認されます。
最終的な結論
選択基準と実験条件に従って、さまざまな成功度でさまざまなサービスとソフトウェア製品の相互互換性をテストすることができました。これについては以下で説明します。 驚くべきことに、Web Call Server 4ミドルウェアを使用して、多くのサービスがWowza Streaming EngineおよびFlash Media Serverストリーミングサーバーにシームレスに統合されました。
特に、次のものがあることを確認できました。
- Zoom.usサービスへの呼び出しと呼び出し制御を開始する機能。
- Zoom.usサービスからの複数の接続を含む、ストリーミングコンテンツをブロードキャストする機能。
- Twilioサービスおよびこのサービスに接続しているサブスクライバーにダイヤルするWeb Call Serverの機能。
- Web Call Serverでの接続の開始と制御が1つのコマンドに制限されていたため、IP-PBX OpenSIPSとVidyoサービスとの統合を介して接続されたサブスクライバーのコールを管理する機能はzoom.usサービスよりも簡単でした。
- Lifesizeサービスは、サービスウィンドウでの高品質ビデオ表示のために主観的に多くの帯域幅を必要としましたが、Blue Jeansサービスはシンプルで、わずか数ステップでBriaラリーとWeb Call Server 4に同時に接続できるようになりました。
すべてのテストは、Wowza Streaming EngineとAdobe Media Serverの2つのストリーミングサーバーで実施されました。
テスト結果は、次の表にまとめられています。
テストの候補を検討する際、利用可能なリンク、サービスのオンラインバージョンが存在しない、または提供しない（およびサーバーにソフトウェアをインストールする必要がある）サービスの一部が非常に機能的な「メッセンジャー」であるか、SIPプロトコルをサポートしないことが判明しました。
私たちが示したサービスとソフトウェアの相互テストの結果は、このリストを使用する他の利害関係者を奨励するものと想定したい：その結果は、このような新しい実験の結果から得られます。
使用したリソース
- トラフィックアナライザー-www.wireshark.org
- Wowzaストリーミングエンジン-www.wowza.com
- Adobe Media Server-www.adobe.com/products/adobe-media-server-family.html
- Web Call Server 4-flashphoner.com
- www.zoom.us
- www.twilio.com
- www.lifesize.com
- www.bluejeans.com
- www.vidyo.com
- www.pgi.com
- CounterPath Software-www.counterpath.com/bria
- ビデオ /オーディオコンテンツ処理ソフトウェア-manycam.com