GB28181は、異なるネットワークや管理プラットフォーム間でビデオ監視リソースを接続するために広く使用されています。実際の展開、特にカメラ、NVR、ビデオプラットフォームがインターネットを介して通信する場合、繰り返し疑問が生じます。GB28181ネットワークに参加するすべてのデバイスに固定パブリックIPアドレスが必要なのでしょうか？

ほとんどの展開では、答えは「いいえ」です。中央のGB28181プラットフォーム、または安定した登録エンドポイントとして機能するゲートウェイは、通常、固定され到達可能なネットワークアドレスを必要とします。カメラ、NVR、その他のフロントエンドデバイスは、そのプラットフォームとの通信を確立でき、必要なシグナリングとメディアパスが正しく設定されている限り、通常はルーター、ファイアウォール、NATゲートウェイの背後に留まることができます。

このアーキテクチャが可能なのは、GB28181がSIPに由来する登録モデルを使用しているためです。中央プラットフォームが各カメラを永続的なパブリックIPアドレスで見つけることを要求する代わりに、フロントエンドデバイスはサーバーに積極的に登録し、通信状態を維持します。これにより、特に監視機器が支店、産業現場、交通施設、キャンパス、倉庫、その他の分散拠点に展開されている場合に、大規模なネットワーク間ビデオ統合がより実用的になります。

プロジェクト設計においては、したがって、単に静的IPが必要かどうかというよりも、どのノードが安定したサービスアドレスを提供する必要があるか、リモートデバイスがそのノードにどう到達するか、NATがどこで発生するか、シグナリングトラフィックとビデオストリームの両方が選択されたネットワークパスを通過できるかどうかをエンジニアが判断することがより有用な質問です。

登録アーキテクチャの仕組み

ネットワーク要件を理解するのに役立つ方法は、GB28181アーキテクチャをSIP通信システムと比較することです。中央GB28181プラットフォームはSIPサーバーに類似した役割を果たし、NVR、カメラ、ビデオゲートウェイ、その他のアクセスデバイスは登録されたエンドポイントのように動作します。

エンドポイントがオンラインになると、設定されたプラットフォームに向けて登録を開始します。プラットフォームは、設定されたデバイスID、認証情報、サーバーアドレス、通信ポートを使用してデバイスを識別し認証します。登録プロセスが成功すると、プラットフォームはそのエンドポイントとの論理的な関係を維持でき、エンドポイント自体が永続的なパブリックインターネットアドレスを公開する必要はありません。

登録後、デバイスは定期的な通信を通じてオンライン状態を維持し続けます。分散展開では、カメラやNVRが外部ネットワーク情報が時間とともに変化するルーターの背後で動作する可能性があるため、これは重要です。エンドポイントが既知のプラットフォームアドレスとの通信を再確立できる限り、中央システムはそれを登録リソースとして管理し続けることができます。

これにより、基本的なネットワークモデルが変わります。重要な要件は、すべてのカメラがグローバルに固定されたアドレスを持つことではなく、デバイスがGB28181サーバーに到達し、使用可能な通信パスを維持できることです。

フロントエンドデバイスが通常パブリックアドレスを必要としない理由

ほとんどの監視デバイスは、もともとローカルエリアネットワーク内で動作するように設計されています。カメラはローカルルーターによって割り当てられたプライベートアドレスを使用し、NVRは同じプライベートネットワーク上の多数のカメラを管理する場合があります。すべてのデバイスに独立したパブリックIPアドレスを付与すると、不要なネットワーク複雑性が増し、多くのインターネット接続が個々のデバイスにパブリック静的アドレスを提供しないため、しばしば不可能です。

これは特に分散監視プロジェクトにおいて重要になります。中央監視プラットフォームは多くの拠点からのビデオリソースを接続する必要があるかもしれませんが、それらの拠点は通常のブロードバンド、企業インターネットアクセス、プライベートネットワーク、またはファイアウォールを使用している場合があります。それらのパブリックアドレスは変更される可能性があり、一部のサイトは監視サブネットをインターネットに直接公開しない場合があります。

登録ベースのアーキテクチャでは、フロントエンドデバイスは既知のGB28181サーバーへの通信を確立します。したがって、サーバーは変化する外部IPアドレスを継続的に追跡することでデバイスを発見する必要はありません。登録状態が有効であり、ネットワークが必要な通信を許可している限り、エンドポイントはシステムへの参加を続けることができます。

これにより、より明確なセキュリティ境界も提供されます。カメラは個別にインターネットアクセス可能なデバイスとして公開される代わりに、監視LAN内に留まることができます。ネットワーク管理者はその後、ルーター、ファイアウォール、ゲートウェイ、またはサイトエッジで外部通信を制御でき、各カメラに個別のパブリックアドレスポリシーを維持する必要がなくなります。

実際には、これはNVR、カメラ、またはアクセスゲートウェイが通常、独自の専用静的パブリックIPではなく、信頼性の高いネットワーク接続を必要とすることを意味します。

シグナリングとビデオトラフィックは異なるパスです

GB28181展開における最も一般的な間違いの1つは、デバイス登録の成功がビデオ接続全体が機能していることを証明すると想定することです。登録は主に、デバイスと中央プラットフォーム間のシグナリングパスが利用可能であることを確認します。実際のライブビデオ伝送は、同様に到達可能でなければならない別のメディアパスを導入します。

そのため、カメラやNVRがプラットフォーム上でオンラインと表示されても、ライブビデオを開くことができない場合があります。この場合、登録プロセスは正しく機能しているかもしれませんが、メディアトラフィックがファイアウォールによってブロックされたり、NATによって誤って変換されたり、到達不能なアドレスにルーティングされたり、誤って設定されたポート範囲によって制限されたりしている可能性があります。

この区別は、ネットワークをまたぐプロジェクトのトラブルシューティングにおいて重要です。エンジニアは、デバイス登録と認証からストリーム要求、メディアセッション確立、継続的なビデオ伝送までの完全なシーケンスを検証する必要があります。シグナリングとメディアを別個だが関連するネットワークパスとして扱うことで、障害の切り分けがはるかに速くなります。

同じ原理は、ビデオが複数のネットワーク境界を越えて伝送される場合にも適用されます。本社プラットフォームはインターネットを介して支店NVRと通信し、NVRは完全にプライベートなサブネット内のカメラからビデオを取得する場合があります。カメラ自体はパブリックネットワークと直接通信することは決してないかもしれませんが、それでもそのストリームはNVRまたはアクセスゲートウェイを介して中央プラットフォームで利用可能になります。

NATとファイアウォールは依然として慎重に計画する必要があります

すべての監視デバイスに固定IPを要求しないことは、ネットワーク設計を無視できることを意味しません。多くのフィールドデバイスはNATルーターやエンタープライズファイアウォールの背後にあり、シグナリングトラフィックとビデオメディアの両方がネットワークを正しく通過する必要があります。

SIPスタイルの登録は、プラットフォームが登録済みエンドポイントの把握を維持するのに役立ちます。定期的な登録、キープアライブ、ハートビートメカニズムも、エンドポイントとサーバー間の通信状態を維持するのに役立ちます。これは、カメラやNVRが外部アドレスが時間とともに変化する可能性のあるルーターの背後にある場合に特に有用です。

ただし、NATトラバーサルはすべてのネットワーク問題に対する自動的な解決策として扱うべきではありません。展開では依然として、ファイアウォールポリシー、アドレス変換動作、シグナリングポート、メディアポート、フィールドネットワークとプラットフォーム間のルーティングを検証する必要があります。

同じ監視機器を使用していても、サイトによって動作が異なる場合があります。ある支店はシンプルなエンタープライズルーターを使用し、別の支店は多層ファイアウォールの背後で動作し、3番目の支店はプライベートWANを介してプラットフォームにアクセスする場合があります。デバイスレベルでのGB28181設定は類似していても、必要なルーティングおよびセキュリティポリシーは大幅に異なる場合があります。

例えば、デバイスはプラットフォームへの登録に成功しても、メディアパスがブロックされているためにライブビデオが失敗することがあります。したがって、登録テストはシステムの一部のみを確認します。完全な試運転プロセスでは、ライブビューイング、ストリーム確立、デバイス制御、一時的なネットワーク中断後の回復も検証する必要があります。

分散サイトのための実用的なアーキテクチャ

インターネットベースの展開では、最もシンプルなアーキテクチャは通常、中央GB28181プラットフォーム、または中央接続ポイントとして機能するGB28181アクセスゲートウェイに、リモートデバイスが継続的に到達できる安定したネットワークアドレスを提供することです。

プラットフォームアドレスは、リモートNVR、カメラ、またはゲートウェイに設定されます。各エンドポイントはその後、ローカルネットワークから中央システムへの登録を開始します。接続はデバイス側から開始されるため、ローカル監視ネットワークは各カメラをパブリックインターネットに直接公開する必要はありません。

典型的な展開は3つの領域に分割できます：

• 中央プラットフォーム：安定して到達可能なGB28181登録エンドポイントを提供し、デバイス登録、認証、シグナリング、ビデオアクセスを管理します。

• IPネットワーク：エンタープライズネットワーク、インターネット、またはその他のルーティング可能な接続を介して、分散サイトと中央システム間の通信を提供します。

• フィールド監視ネットワーク：ルーターまたはファイアウォールの背後にあるローカルアドレッシングを使用したNVR、カメラ、および関連機器を含みます。

小規模プロジェクトでは、リモートサイトが複数のカメラチャンネルを含む1台のNVRを登録する場合があります。大規模プロジェクトでは、複数のNVR、ビデオゲートウェイ、または直接接続されたGB28181対応デバイスが独立して登録する場合があります。正しい構造は、監視リソースがどのように組織化されているか、および中央プラットフォームが個々のデバイスに対してどの程度の制御を必要とするかによって異なります。

産業団地、交通施設、複数支店を持つ組織では、サイトレベルのアクセスモデルがしばしば運用しやすくなります。なぜなら、ローカルデバイスは既存のLANアーキテクチャ内に留まるからです。ネットワーク管理者は、必要なアクセスノードが中央システムと確実に通信できることを確認するだけで済みます。

このモデルは、すべての監視エンドポイントにパブリックIPアドレスを割り当てるよりもはるかに拡張性があります。新しいサイトが追加される場合、主なタスクは中央プラットフォームへのネットワーク到達性を提供し、デバイス登録を正しく設定することであり、すべてのカメラのパブリックアドレッシングを再設計することではありません。

ネットワーク容量はIPアドレッシング以上に重要です

正しいIPアーキテクチャは、利用可能なネットワーク容量が不十分な場合、良好なビデオパフォーマンスを保証しません。GB28181プロジェクトは多くのチャンネルが中央拠点にビデオを伝送することを含む可能性があるため、帯域幅計画はアドレッシング、ルーティング、ファイアウォール設定とともに考慮する必要があります。

同じリモートサイトから複数の高解像度ストリームが同時に要求される場合、サイトのアップストリーム帯域幅が真のボトルネックになる可能性があります。プラットフォームはすべてのデバイスをオンラインと表示する一方で、オペレーターはストリームオープンの遅延、パケット損失、不安定な再生、またはビデオの中断を経験するかもしれません。

この理由から、システム計画は登録されたカメラの総数だけでなく、同時に視聴されるチャンネル数を考慮する必要があります。数百台のカメラを含むサイトでも、同時に外部に伝送されるストリームが少なければ、WANへの負荷はわずかです。逆に、はるかに小さいサイトでも、多くのチャンネルを監視センターで継続的に視聴する必要がある場合、かなりの帯域幅を必要とする可能性があります。

したがって、リモートコマンドセンター、集中録画、または継続的なネットワーク間監視を含むプロジェクトは、設計段階で利用可能なアップリンク容量、ネットワーク品質、予想される同時ストリーム数を評価する必要があります。

静的パブリックIPが実際に必要とされる場合

従来の集中型GB28181展開では、最も重要な固定アドレスは通常、デバイス登録を受信するプラットフォームまたはゲートウェイのアドレスです。リモートエンドポイントは登録要求をどこに送信するかを知っている必要があるため、このサーバー側アドレスは安定しており、一貫して到達可能であるべきです。

プラットフォームのパブリックアドレスが頻繁に変更されると、リモート機器は古い宛先への登録を試み続ける可能性があります。これにより、アドレス発見やネットワーク管理に追加の要件が生じます。したがって、固定パブリックIPはプラットフォーム展開を簡素化し、中央接続ポイントの不確実性を低減します。

対照的に、プラットフォームに積極的に登録するNVRやカメラは、通常同じ扱いを必要としません。インターネットまたはルーティング可能なネットワークアクセスを持ち、必要なGB28181通信がローカルネットワークインフラストラクチャを通過できる限り、プライベートネットワーク内に留まることができます。

一部のプロジェクトでは、パブリックインターネットではなく、プライベートリースネットワーク、VPN、またはエンタープライズWANを使用します。これらの環境では、プラットフォームとフィールドデバイスの両方がルーティング可能なプライベートアドレスを介して通信するため、パブリックIPがまったく不要な場合があります。重要なのは、プラットフォームが選択されたネットワークアーキテクチャ内で安定した宛先を提供することです。

結果として得られる設計原則は簡単です：中央サービスエンドポイントを安定に保ち、展開が許す限りフィールドデバイスが実用的なローカルネットワークアドレッシングを使用できるようにします。

展開の推奨事項

新しいGB28181ネットワーキングプロジェクトでは、IP計画はデバイス単位ではなくシステムレベルで実行する必要があります。安定した登録エンドポイントとして機能するコンポーネントを決定することから始めます。次に、各フィールドネットワークがそのエンドポイントにどのように到達し、シグナリングとビデオメディアがネットワークパスを通過できるかを確認します。

設計では、アドレス変換がどこで発生するかも特定する必要があります。中央プラットフォームとフィールド機器の両方が異なるNATデバイスの背後にある場合、中央エンドポイントが直接到達可能なトポロジーよりも通信が複雑になる可能性があります。個々のデバイスを設定する前に完全な経路を理解することで、後での繰り返しのトラブルシューティングを防ぐことができます。

試運転中は、基本的な登録以上のテストを行います。ライブビデオアクセス、ストリーム安定性、ネットワーク中断後の再接続、長時間のデバイスステータス維持を検証します。複数のリモートサイトが関与する場合は、代表的なネットワーク環境をテストします。異なるルーターやファイアウォールポリシーが異なる結果を生む可能性があるためです。

現実的な運用条件をシミュレートすることも有用です。複数のストリームを同時に開き、WAN接続を切断および復旧し、NVRを再起動して、エンドポイントが自動的にプラットフォームに戻ることを確認します。これらのテストは、短い単一チャンネルのデモンストレーションでは現れない問題を明らかにします。

大規模システムの場合は、プラットフォームアドレス、サイトネットワーク範囲、デバイスID、登録関係、シグナリングポリシー、メディアポート要件の明確な記録を維持します。このドキュメントは、数百または数千の監視リソースが接続される際の後の拡張とトラブルシューティングを大幅に容易にします。

このアプローチは不要なパブリックIP割り当てを回避し、アーキテクチャを拡張に適した状態に保ちます。新しいNVR、カメラ、またはリモートサイトは、各監視デバイスを直接公開されたインターネットエンドポイントにすることなく、同じ登録モデルを介して追加できます。

結論

GB28181ビデオネットワーキングは、通常すべてのNVRまたは監視カメラに固定パブリックIPアドレスを必要としません。システムはSIP由来の登録メカニズムを使用するため、リモートデバイスは中央プラットフォームに積極的に登録し、登録およびハートビートプロセスを通じて通信を維持できます。

典型的なインターネットベースのアーキテクチャでは、GB28181プラットフォームまたは中央アクセスゲートウェイが安定して到達可能なアドレスを提供する必要があります。NVRとカメラは、プラットフォームに到達でき、必要なシグナリングおよびメディアパスが正しく設定されている限り、ローカルルーター、NATデバイス、ファイアウォールの背後に留まることができます。

大規模プロジェクトでは、真の設計優先事項はすべてのデバイスに静的IPアドレスを割り当てることではなく、安定した中央エンドポイント、予測可能なルーティング、正しいファイアウォールポリシー、十分な帯域幅、および参加するすべてのネットワーク間での信頼性の高い登録およびメディア通信を構築することです。

FAQ

中央GB28181プラットフォームにドメイン名を使用できますか？

これは、接続する機器がドメイン名設定をサポートし、DNS解決を確実に処理できるかどうかに依存します。相互運用性が不確かな場合、安定したIPエンドポイントは一般的に単純な展開モデルを提供します。

中央プラットフォームがキャリアグレードNATの背後に置かれた場合はどうなりますか？

リモートネットワークから直接到達できないプラットフォームには、パブリックフェーシングゲートウェイ、専用ルーティング、またはその他の制御された接続方法などの追加のネットワーク構成が必要になる場合があります。重要な要件は、参加デバイスが一貫して登録サービスに到達できることです。

中央システムは冗長ネットワークアドレスを使用できますか？

システムアーキテクチャでサポートされている場合、冗長展開は可能ですが、フェイルオーバー動作はエンドポイント登録ルールとともに計画する必要があります。デバイスは、プライマリサービスエンドポイントが利用不能になったときにどのように再接続するかを知っている必要があります。

クラウド展開はGB28181プラットフォームに適していますか？

クラウド環境は、そのパブリックアドレッシング、ルーティング、ファイアウォール、メディアポートポリシーが監視システム向けに設定されていれば、必要なネットワーク到達性を提供できます。プラットフォームがローカルデータセンターで実行されるかクラウドインフラストラクチャで実行されるかに関係なく、同じ接続原則が適用されます。

NVRを使用するとGB28181登録数が減少しますか？

可能性があります。NVRが複数のカメラチャンネルを1台のGB28181対応デバイスを介して公開する場合、中央プラットフォームは各カメラが独立したネットワーク間登録を確立することを要求する代わりに、NVRを介してそれらのチャンネルを管理できます。実際の動作は機器とプロジェクトアーキテクチャに依存します。