大規模なビデオ監視システムは一般的にGB28181を使用して、カメラ、NVR、および多層監視リソースを集中プラットフォームの下で整理します。しかし、ユニファイドコミュニケーションおよび緊急指令システムは、標準SIPを中心に構築されることがより一般的です。GB28181もシグナリングアーキテクチャの一部としてSIPを使用していますが、従来のSIP通信システムと直接同等ではありません。これら2つの環境が連携する必要がある場合、GB28181からSIPへのゲートウェイは、既存のプラットフォームの大規模な再開発を必要とせずに実用的な相互運用レイヤーを提供します。

ゲートウェイは、既存のGB28181プラットフォームから監視リソースを取得し、選択したカメラチャンネルをSIPアクセス可能なビデオリソースに変換し、必要に応じてH.264およびH.265ストリームを適応させ、FLV、HLS、WebRTC、RTMP、RTSPなどの追加のメディア出力を提供できます。これにより、固定カメラやその他のビデオソースを指令コンソール、緊急指令アプリケーション、その他のSIPベースの通信ワークフローに組み込むことが可能になります。

相互運用レイヤーが必要な理由

従来の監視プラットフォームとユニファイドコミュニケーションシステムは、異なる運用目標を中心に設計されています。監視側はカメラの整理、ライブビデオへのアクセス、多数の監視リソースの管理に焦点を当てています。通信側は通話、指令運用、およびユーザーと端末間のリアルタイムインタラクションに焦点を当てています。

GB28181は監視ネットワーキングの標準化されたフレームワークを提供し、ビデオリソースが異なる地域や管理レベルに分散している場合に特に有用です。GB28181プラットフォームはデバイスディレクトリを維持し、多数のカメラ、NVRチャンネル、その他のビデオリソースを整理できます。

SIPベースの通信プラットフォームは異なるサービスモデルを使用します。SIP端末は通常、呼び出し可能な通信エンドポイントとして扱われます。指令員がエンドポイントを選択すると、システムはSIPシグナリングプロセスがセッションを確立することを期待します。GB28181監視プラットフォームによって管理されるカメラは、この形式で自動的に通信システムに提示されるわけではありません。

この違いは、緊急指令および統合通信プロジェクトにおいて実用的な問題となります。オペレーターはすでに電話、指令端末、その他のSIPユーザーにアクセスできるかもしれませんが、ライブ監視ビデオは別の監視プラットフォーム内に隔離されたままです。相互運用メカニズムがないと、2つのシステム間の切り替えに運用ステップが追加され、通信とビデオ情報を1つのワークフローに組み合わせる能力が制限されます。

2つのシステム間に直接ソフトウェアインターフェースを開発することは可能ですが、大幅なプロトコル適応、メディア処理、および互換性テストが必要になる場合があります。専用ゲートウェイは、GB28181とSIP環境間のプロトコルとメディアの違いを処理することで、この統合作業の負担を軽減します。

監視リソースのSIPエンドポイントへの変換

プロトコル変換はソリューションの中核機能です。ユニファイドコミュニケーションシステムに完全なGB28181監視構造を直接理解させる代わりに、ゲートウェイは一方のビデオリソースを解釈し、必要なチャンネルをもう一方のSIP環境に提示します。

ゲートウェイは既存のGB28181プラットフォームに接続し、そのビデオリソース構造を取得できます。これは、監視ネットワークがすでに展開され、多数のカメラを含むプロジェクトに特に有用です。既存のプラットフォームは監視組織の責任を引き続き担い、ゲートウェイは通信システムに参加する必要のあるリソースを選択して公開します。

その後、カメラリソースはSIPプラットフォームが使用できる形式にマッピングできます。指令システムの観点からは、選択された監視チャンネルは呼び出し可能なビデオエンドポイントのように動作できます。指令員はビデオが必要になるたびに基礎となるGB28181シグナリングプロセスを理解する必要はありません。

典型的なインタラクションは次のように構成できます：

• ゲートウェイは既存のGB28181ビデオプラットフォームに接続し、利用可能な監視リソースを読み取ります。

• 必要なカメラまたはビデオチャンネルがSIP通信環境で使用するためにマッピングされます。

• 指令端末またはその他の認可されたSIPエンドポイントが標準通信ワークフローを開始します。

• ゲートウェイはリクエストを監視側で必要なシグナリングに変換します。

• 対応するカメラストリームが取得され、通信アプリケーションに配信されます。

このアプローチは既存の監視プラットフォームの役割を維持しながら、通信システムへの制御されたブリッジを追加します。ビデオが指令アプリケーション内に表示される必要があるという理由だけで、カメラ管理を完全に再構築する必要を回避します。

既存のビデオリソースへの柔軟なアクセス

有用なゲートウェイは、実際のプロジェクトが単一のデバイスタイプを中心に構築されることはめったにないため、複数の監視アクセス方法をサポートする必要があります。

大規模な展開では、通常、既存のGB28181プラットフォームに接続することが好ましい方法です。プラットフォームには既に数千の監視リソースが含まれ、独自のデバイス階層を維持している場合があります。ゲートウェイは各カメラを個別に接続する代わりに、その既存の構造をビデオリソースのソースとして使用できます。

これにより、プロジェクトはカメラ、NVR、および監視プラットフォーム間の既存の管理関係を維持できます。また、新しく管理されるビデオリソースは、通信プラットフォーム内で個別に再構築されるのではなく、監視システムを通じて引き続き組織化できるため、後の拡張が簡素化されます。

他のプロジェクトでは、すべてのサイトに完全なGB28181プラットフォームがない場合があります。そのような場合、ゲートウェイはNVRまたは互換性のあるIPカメラをアクセスソースとして使用することもできます。これは、小規模なリモートサイト、一時的な監視場所、または選択されたカメラのみをユニファイドコミュニケーション環境に導入する必要があるプロジェクトに有用です。

したがって、アクセスアーキテクチャは既存のネットワークに応じて選択できます：

• プラットフォームレベルのアクセス：集中リソースディレクトリを持つ確立されたGB28181監視システムに適しています。

• NVRレベルのアクセス：複数のローカルカメラチャンネルがすでにレコーダーに集中している場合に適しています。

• カメラレベルのアクセス：直接統合が必要な選択された互換性のあるカメラに適しています。

この柔軟性は、既に正常に動作している機器の不要な交換を減らすため、レトロフィットプロジェクトにおいて重要です。

コーデックとストリームの適応が互換性を向上させる

プロトコル変換だけでは、すべての通信端末でビデオが正しく表示されることは保証されません。監視システムとリアルタイム通信アプリケーションは、異なるビデオエンコーディングおよび再生機能を使用する場合があります。

H.264とH.265はどちらも監視環境で広く見られます。H.265は高解像度監視ビデオの帯域幅要件を削減できますが、一部の通信アプリケーションやブラウザベースの端末は、専用監視ソフトウェアと同じようにはサポートしない場合があります。

ゲートウェイは必要に応じてH.264とH.265間のトランスコーディングを提供できます。これにより、カメラは監視ネットワークに適したエンコーディングモードを引き続き使用しながら、受信通信システムはデコード可能なストリームを取得できます。

コーデック変換はメディア適応の一部に過ぎません。異なるエンドポイントは解像度、フレームレート、ビットレートについても異なる要件を持つ場合があります。監視カメラは高品質録画用に設定されているかもしれませんが、同じストリームは制約されたネットワーク上の小さな指令ウィンドウで表示される場合、不必要に要求が高くなる可能性があります。

これらのメディアパラメータを適応させることにより、ゲートウェイは受信システムにより適したストリームを作成できます。これは、ビデオが異なるエンドポイントタイプに配信される場合や、通信リンクの利用可能な帯域幅が異なる場合に特に価値があります。

目的は単にビデオ品質を低下させることではありません。目的は、監視ソースを受信アプリケーションの機能および動作条件に合わせて、ビデオが通信ワークフロー全体を通じて使用可能な状態を維持することです。

1つのビデオソースで複数のアプリケーションに対応

ビデオ統合は、単一のSIP通話を超えて拡張されることがよくあります。緊急指令センター、ブラウザアプリケーション、大画面可視化システム、サードパーティのビジネスプラットフォームがすべて同じ監視リソースにアクセスする必要がある場合があります。

このため、GB28181からSIPへのゲートウェイはメディア配信ポイントとしても機能できます。GB28181接続およびSIP指向の統合に加えて、メディアレイヤーは以下のような一般的なストリーミング形式およびプロトコルを提供できます：

• FLV 互換性のあるWebおよびストリーミングアプリケーション向け。

• HLS HTTPベースのビデオ配信向け。

• WebRTC 低遅延ブラウザベースの通信シナリオ向け。

• RTMP ストリーミングおよびパブリッシングワークフロー向け。

• RTSP 従来のリアルタイムストリームアクセスを必要とするアプリケーション向け。

• GB28181アップリンク ビデオリソースが標準ベースの監視階層に引き続き参加する必要がある場合。

複数の出力オプションにより、アプリケーションごとに個別の変換システムを導入する必要性が減ります。単一の監視リソースを既存のビデオ環境から取得し、受信プラットフォームの要件に応じて異なる形式で配信できます。

これは、同じインシデントが指令コンソール、ブラウザベースのアプリケーション、および大画面ディスプレイによって同時に表示される可能性がある指令センターのプロジェクトで特に有用です。ゲートウェイは、各サブシステムに独立したカメラ接続を再構築する代わりに、共通のメディア統合レイヤーを提供できます。

モバイルビデオを指令センターに持ち込む

同じメディアゲートウェイアーキテクチャは、恒久的に設置されたCCTVカメラを超えて拡張できます。緊急運用では、既存の監視リソースと組み合わせる必要のある一時的およびモバイルビデオソースが使用されることがよくあります。

例としては、ドローン、ポータブル監視カメラ、ボディ装着型記録デバイスが挙げられます。これらのソースはインシデント場所に一時的に展開され、固定カメラでは捉えられない情報を提供できます。

統合メディアアクセスレイヤーにより、これらのストリームを従来の監視カメラとともに指令ワークフローに導入できます。オペレーターはデバイスカテゴリごとに個別のアプリケーションを開く代わりに、同じ指令環境を通じて異なるソースを表示できます。

産業施設での緊急対応シナリオを考えてみましょう。固定カメラは入り口、生産エリア、周辺道路の継続的なビューを提供できます。ポータブルカメラはインシデントの近くに配置でき、ドローンは上からの全体像を提供します。現場要員はウェアラブル記録機器を介してビデオを送信することもできます。

これらのビデオソースがメディア統合レイヤーを介して接続されると、指令センターはそれらをSIPベースの通信と組み合わせることができます。指令員は担当者と通信しながら関連するビデオリソースを同時に確認できるため、オペレーターが無関係なシステム間を繰り返し移動することを強制することなく、状況認識を向上させることができます。

統合を完全なワークフローとして設計する

成功する展開は、ゲートウェイを孤立したプロトコルコンバータとして扱うのではなく、運用ワークフローを中心に設計する必要があります。

最初のステップは、既存のビデオリソースがどこで管理されているかを特定することです。GB28181プラットフォームがすでに完全なディレクトリを提供している場合、プラットフォームレベルの統合は、数百台のカメラを個別に接続するよりも一般的に効率的です。関与するビデオリソースが少数の場合、直接のNVRまたはカメラアクセスで十分な場合があります。

次のステップは、ユーザーが通信システムからビデオにどのようにアクセスするかを決定することです。一部のプロジェクトでは、指令コンソールに埋め込まれた監視画像のみが必要です。他のプロジェクトでは、SIPビデオ通話、ブラウザ再生、大画面表示、およびサードパーティアプリケーションアクセスが同時に必要です。

コーデックの互換性も展開前に確認する必要があります。監視カメラで使用されるエンコーディングを、指令端末、ブラウザ、その他の受信アプリケーションのデコード機能と比較する必要があります。これらの機能が異なる場合、トランスコーディングはすべてのカメラを変更するのではなく、必要なストリームにのみ導入できます。

ネットワーク容量はビデオ適応とともに考慮する必要があります。ローカル録画に適したカメラストリームは、WANを介して送信される場合に必要以上に帯域幅を消費する可能性があります。したがって、解像度、フレームレート、ビットレートは、ビデオが実際にどのように使用されるかに応じて計画できます。

最後に、コミッショニングは完全なワークフローをテストする必要があります。エンジニアは、ゲートウェイがカメラストリームを取得できることだけでなく、認可されたSIPユーザーが正しいチャンネルにアクセスできること、期待されるコーデックが配信されること、メディア再生が安定していること、必要な外部ストリーミングインターフェースが正しく動作することを検証する必要があります。

このアーキテクチャが最も価値を発揮する場所

このソリューションは、組織がすでに独立した監視システムと通信システムを持ち、完全なプラットフォーム交換なしにそれらを連携させる必要がある場合に特に有用です。

緊急指令センターでは、監視ビデオを指令活動に関連付けて、オペレーターが影響を受ける場所を表示しながら通信できるようにします。産業施設では、既存のCCTVリソースをインシデント処理および運用調整に使用される通信コンソールに導入できます。

複数サイト組織は、確立されたGB28181監視階層を維持しながら、選択されたリソースを中央通信プラットフォームで利用できるようにすることができます。インシデントが追加の視覚的カバレッジを必要とする場合、一時的なビデオソースも導入できます。

主なアーキテクチャ上の利点は、各既存システムが元の役割を引き続き実行できることです。監視プラットフォームはビデオリソースの組織化を引き続き担当し、ユニファイドコミュニケーションシステムはSIP通信と指令ワークフローを引き続き担当します。ゲートウェイはその間に必要なプロトコルおよびメディア変換を処理します。

結論

GB28181からSIPへのゲートウェイは、どちらもIPビデオを扱うが異なる通信モデルを使用する2つのシステム間の橋渡しをする実用的な方法を提供します。既存のGB28181監視環境に接続し、カメラおよびNVRリソースを取得し、選択したビデオチャンネルをSIPアクセス可能なエンドポイントに変換し、ソースと宛先が異なるエンコーディング要件を使用する場合にメディアを適応させることができます。

基本的なプロトコル変換に加えて、H.264およびH.265トランスコーディング、フレームレート、ビットレート、解像度の調整のサポートは、監視デバイスと通信アプリケーション間の実際の互換性問題の解決に役立ちます。FLV、HLS、WebRTC、RTMP、RTSP、GB28181などの出力により、同じビデオリソースをより広範な指令および可視化アプリケーションに提供することも可能になります。

緊急指令および統合通信プロジェクトにとって、ゲートウェイの価値は2つのプロトコルを接続することに限定されません。そのより重要な役割は、再利用可能なビデオ相互運用レイヤーを作成し、固定カメラ、NVRリソース、およびモバイルビデオソースがSIPベースの通信と同じ運用ワークフローに参加できるようにすることです。

よくある質問

ゲートウェイの導入には既存のビデオ管理プラットフォームの交換が必要ですか？

通常は必要ありません。統合は既存の監視階層を中心に設計でき、現在のプラットフォームがカメラを引き続き管理しながら、選択されたリソースがゲートウェイを介して他のシステムに公開されるようにすることができます。

監視ユーザーと通信ユーザーでアクセス権限を異なるものにできますか？

周辺プラットフォームに応じて個別に設計できます。プロジェクトは、監視ディレクトリ全体をすべての通信ユーザーに自動的に公開するのではなく、統合レイヤーを通過できるビデオリソースを定義する必要があります。

すべてのビデオストリームをトランスコードすべきですか？

必ずしもそうではありません。トランスコーディングは、ソースエンコーディングを受信エンドポイントがデコードできない場合、または元のメディアパラメータがターゲットネットワークまたはアプリケーションに適していない場合に最も有用です。不要な変換を避けることで処理要件を削減できます。

ビデオがWebアプリケーションに表示される必要がある場合、ゲートウェイを使用できますか？

はい、選択されたゲートウェイアーキテクチャがWebRTC、HLS、またはFLVなどのWeb互換メディア出力を提供する場合に可能です。最終的な選択は、レイテンシ、ブラウザ互換性、およびアプリケーションの設計方法に依存します。

大規模なカメラディレクトリを接続する前に何をテストすべきですか？

まず代表的なカメラチャンネルを検証することをお勧めします。異なるコーデックと典型的なビデオプロファイルを含めます。これにより、統合をより大規模なリソースディレクトリに拡張する前に、シグナリング、デコード、ネットワーク互換性の問題を明らかにできます。