着信は、オペレータに状況が求める運用コンテキストよりも少ない情報しか提供しないことがよくあります。発信者は入口の閉鎖、安全インシデント、機器の問題などを説明するかもしれませんが、オペレータは依然として場所を特定し、正しいカメラを見つけ、別の監視アプリケーションを開く必要があります。コールセンターをビデオ監視プラットフォームに接続することで、通話処理中に関連するライブビューをオペレータのワークスペースに表示できます。

このソリューションは、コールセンターをビデオ管理システムの代替にするものではありません。通話イベント、位置データ、カメラリソースを連携させることで、オペレータは状況をより迅速に確認し、セキュリティ、メンテナンス、または指揮要員により良い情報を渡すことができます。これは、公共安全センター、観光地、産業サイト、鉱山、キャンパス、大規模ビジネスパークなど、通話が物理的な場所に関連付けられている場合に特に有用です。

音声だけではインシデント処理が遅くなる理由

従来のコールセンターは、会話と顧客記録を中心に設計されています。その主な機能には、電話交換機または自動コールディストリビュータ、インタラクティブ音声応答（IVR）、コンピュータテレフォニーインテグレーション（CTI）、顧客関係管理（CRM）、通話録音、スタッフスケジューリング、レポート作成、オペレータ電話またはソフトフォンなどが含まれます。

監視システムは異なる方法で構成されています。カメラ、ネットワークビデオレコーダ（NVR）、ビデオ管理プラットフォームは、サイト、建物、フロア、ゾーン、またはデバイスグループごとに配置されます。オペレータは通常、専用の監視クライアントから検索および表示を行います。両方のシステムは単独でも十分に機能しますが、互いのイベントやリソースを自動的に理解することはありません。

遅延は両者の境界で発生します。オペレータは追加の場所に関する質問をし、別のアプリケーションを開き、長いカメラツリーを検索し、どのビューが関連しているかを判断しようとします。発信者が動揺していたり、サイトに詳しくなかったり、共有電話を使用している場合、最初の位置推定でさえ不確かになることがあります。実用的な統合は、オペレータが最終的なカメラ選択を制御し続けながら、これらの手動ステップを削減します。

統合が必要なシステムとデータ

統合レイヤは、CTIまたはビジネスアプリケーションと既存のビデオプラットフォームの間に位置します。コールセンター側では、着信、応答、転送、切断などのイベントと、利用可能な発信者番号、アカウント、内線、サービスチケット、アラームソース、または位置参照を受信します。監視側では、カメラディレクトリを同期し、承認されたデバイスのライブストリームを要求します。

監視プラットフォームがGB/T 28181カスケードをサポートしている場合、ビデオアクセスゲートウェイは上位プラットフォームとして登録し、既存のデバイス階層を取得できます。このアプローチは通常、カメラやNVRの交換を回避します。ビデオ管理者は、現在のプラットフォーム上で承認されたカスケード関係、デバイス権限、カタログ範囲を設定します。GB/T 28181を使用しない環境では、ビデオプラットフォームがサポートするノースバウンドAPIまたは標準アクセスインターフェースを介して同じ統合パターンを実装できます。

接続は単一のインターフェースではなく、いくつかの調整された交換として扱う必要があります。CTIは通話シグナリングとオペレータステータスを提供し、ビジネスアプリケーションはケースコンテキストを提供し、位置サービスは物理エリアを解決し、ビデオプラットフォームはデバイスカタログとメディアセッションを提供します。これらの責任を分離することで、一時的なビデオ問題が通話処理を中断することを防ぎ、各システムを既存の管理者の下に維持できます。

カメラカタログは、通話が到着するたびに再構築するのではなく、キャッシュして制御された間隔で更新する必要があります。各同期レコードには、安定したデバイス識別子、表示名、親サイト、オンラインステータス、サポートされるストリーム情報が必要です。カメラの名前が変更されたり別のグループに移動された場合、統合サービスは元の識別子を参照する履歴イベントレコードを壊さずにメタデータを更新する必要があります。

設計原則：各カメラに個別の接続を開く代わりに、可能な限りビデオプラットフォームと統合します。プラットフォームはすでにデバイス登録、録画、権限、ヘルスステータスを管理しており、統合レイヤはそれらの制御を再利用すべきです。

着信から正しいカメラへ

有用なワークフローはイベント駆動型です。ソフトフォンの隣にビデオプレーヤーを置くだけではありません：

1. 通話イベントをキャプチャします。 CTIサービスが着信を報告し、その時点で利用可能な識別子を提供します。

2. 可能性のある場所を解決します。 ルールサービスが発信者プロファイル、内線プラン、アラーム記録、GISデータベース、または未処理のサービスチケットをチェックします。結果が正確でない場合は、正確なポイントを知っているふりをするのではなくゾーンを返します。

3. 関連カメラを見つけます。 場所をカメラ座標、サイト構造、カバレッジタグ、事前定義された関係と比較します。システムは、手動検索を維持しながら、近くまたは運用上関連するカメラをランク付けできます。

4. 再生可能なストリームを要求します。 ビデオアクセスレイヤがデバイスの可用性を検証し、承認されたストリームをオペレータアプリケーションがサポートする形式に変換または中継します。

5. コンテキスト内でビューを表示します。 デスクトップに通話記録、場所、提案カメラを一緒に表示します。イベントに応じて、オペレータはシングルビューまたは2、4、9、16ウィンドウレイアウトを使用できます。

6. オペレータのアクションを記録します。 カメラ選択、通話識別子、ケースアクションを同じイベントに関連付けて、後で応答をレビューできるようにします。

運用上の場所を中心にマッピングを構築する

電話番号とカメラIDは、有用な命名構造を共有することはめったにありません。したがって、マッピングデータベースがソリューションの中心となります。顧客アカウントをサイトに、内部内線を建物に、緊急端末を固定座標に、またはアラームコードを保護ゾーンに関連付けることができます。カメラレコードには、緯度経度、フロア、視野方向、カバレッジエリア、入口名、ビジネス優先度を含めることができます。

正確な座標が常に利用可能とは限らないため、検索サービスはエイリアスと近似マッチングをサポートする必要があります。たとえば、「北門」に関連する通話は、最初に門のカメラを返し、近くの道路や駐車場のカメラを代替として返すことができます。これは、ソースデータが一般的なエリアのみを示している場合に、単一のビューを確実であるとして静かに提示するよりも安全です。

オペレータインターフェースを集中させ続ける

オペレータは完全な監視コンソールを学習する必要はありません。埋め込みパネルには、サービスプロセスに必要な機能（提案カメラを開く、近くのビューに切り替える、1ストリームを拡大する、分割画面レイアウトを選択する、検証済みの場所を別のチームに渡す）のみが必要です。より高度なビデオ調査は、専用の監視クライアントに残すことができます。

音声分析もイベントシグナルに貢献できます。設定されたフレーズやインシデントカテゴリが検出された場合、システムはカメラグループを提案したりビデオパネルを開いたりできます。最終決定ではなくワークフローを支援すべきであり、オペレータは依然として場所とビューを確認する必要があります。

配信方法の選択

監視ネットワーク内で使用されるビデオプロトコルは、ブラウザやオペレータ端末に配信される形式である必要はありません。アクセスレイヤは、エンドポイントと運用ニーズに合わせてストリームを適応させることができます。最終的な選択は、遅延、ブラウザサポート、ネットワーク条件、同時視聴数、双方向セッション制御の必要性に依存します。

混合デプロイメントは一般的です。同じ統合サービスが、オペレータブラウザにはWebRTC、ディスパッチコンソールにはSIP、最低遅延よりも広い互換性を必要とするスーパーバイザにはHLSを使用することがあります。プロトコルの選択は、システム全体の単一の好みではなく、エンドポイントとワークフローに従うべきです。

ストリームのライフサイクル管理はプロトコル選択と同様に重要です。ストリームは承認されたオペレータのためにのみ作成され、通話、相談、またはレビューセッションが終了したら解放されるべきです。サービスはまた、同じイベントに対して繰り返しポップアップが重複したメディアセッションを開くことを防ぐ必要があります。複数のオペレータが1つのケースで協力する場合、プラットフォームはアップストリームのカメラフィードを再利用し、各ユーザーに個別の閲覧権限と監査記録を維持できます。

展開と受け入れテストの計画

1. トリガーとレスポンスを定義する

少数の高価値イベントから始めます。ビデオパネルがいつ開くか、どのデータが場所を識別するか、カメラがどのようにランク付けされるか、信頼できるマッチングが見つからない場合にオペレータが何をすべきかを指定します。これにより、技術的に成功した統合がルーチン通話中に不要なポップアップを作成することを防ぎます。

2. カメラカタログを正規化する

監視プラットフォームから承認されたディレクトリをインポートし、マッチングに使用されるメタデータをクリーンアップします。重複名、欠落したフロア情報、古い座標は、プロトコル接続が安定していても精度を低下させます。展開を拡大する前に、一貫したサイト、ゾーン、カバレッジラベルを割り当てます。

3. APIを介してオペレータアプリケーションを接続する

CTIまたはCRMインターフェースは、カメラ検索、ストリーム作成、イベントロギングのために統合サービスを呼び出す必要があります。これにより、プロトコル処理をビジネスアプリケーションの外に保ち、後でビデオプラットフォーム、プレーヤー、または配信方法を変更しやすくなります。

4. 完全な運用パスをテストする

受け入れは、成功した再生だけでなく、カタログ同期、カメラのオンライン/オフラインステータス、位置マッチング、手動検索、オペレータ間の転送、認可、中断後のストリーム復旧、イベント相関を検証する必要があります。必要な1、2、4、9、16ビューのレイアウトを、実験室環境だけでなく実際のオペレータコンピュータとネットワークでテストします。

5. ソリューションを段階的に導入する

制御された最初のフェーズでは、オペレータデスクトップ内で手動カメラ検索を提供できます。次のフェーズではルールベースの提案を追加し、その後、信頼性の高い位置データを持つイベントに対して自動ポップアップを追加します。音声分析とより複雑なディスパッチ連携は、基礎となるマッピングと運用手順が証明された後にのみ追加すべきです。

6. 劣化条件に備える

カメラ、ゲートウェイ、またはメディアサービスが利用できない場合でも、通話ワークフローは使用可能な状態を保つ必要があります。オペレータインターフェースは明確なステータスを表示し、音声通話を維持し、無限のローディングウィンドウを表示する代わりに手動検索または近くのカメラを提供するべきです。リカバリテストには、切断されたカメラ、中断されたゲートウェイ接続、遅延したカタログ更新、優先ストリーム形式を開始できないブラウザを含めるべきです。各障害は、オペレータに不要な技術メッセージを公開せずに有用な運用ログを作成する必要があります。

ソリューションが最も適するケース

最も強いユースケースは1つの特徴を共有します。通話が1台または複数のカメラに関連付けられる実際の場所を指していることです。

• 公共安全とインシデント受付：オペレータは発信者の説明を収集し、派遣記録を準備しながら周辺エリアを確認できます。

• 観光地：訪問者が支援を求める際に、サービスセンターは入口、交通ポイント、混雑ゾーンを確認できます。

• 工場や鉱山：管制室はメンテナンス、安全、生産に関する通話を正しい工場、ゲート、または運用エリアに関連付けることができます。

• キャンパスやビジネスパーク：中央サービスデスクは、固定ヘルプポイント、建物、管理された内線からの通話が到着した際に近くのカメラを表示できます。

• 統合指揮センター：同じカメラ選択を、位置情報、インシデント管理、派遣アプリケーションと共有して、協調的な対応を支援できます。

価値はワークフローから生まれ、より多くのビデオを表示することからではありません。適切に設計された統合は、オペレータに最小限の関連ビューセットを提供し、不確実性を可視化し、コールセンターと監視チームの既存の責任を維持します。

よくある質問