대규모 비디오 감시 시스템은 일반적으로 GB28181을 사용하여 카메라, NVR 및 다중 레벨 모니터링 리소스를 중앙 집중식 플랫폼 아래에 구성합니다. 그러나 통합 커뮤니케이션 및 비상 지휘 시스템은 표준 SIP를 중심으로 구축되는 경우가 더 많습니다. GB28181은 시그널링 아키텍처의 일부로 SIP를 사용하지만, 기존 SIP 통신 시스템과 직접적으로 동일하지는 않습니다. 이 두 환경이 함께 작동해야 할 때 GB28181 to SIP 게이트웨이는 기존 플랫폼 중 하나를 광범위하게 재개발하지 않고도 실용적인 상호 운용성 계층을 제공합니다.

게이트웨이는 기존 GB28181 플랫폼에서 감시 리소스를 획득하고, 선택한 카메라 채널을 SIP 액세스 가능한 비디오 리소스로 변환하며, 필요 시 H.264 및 H.265 스트림을 적응시키고 FLV, HLS, WebRTC, RTMP 및 RTSP와 같은 추가 미디어 출력을 제공할 수 있습니다. 이를 통해 고정 카메라 및 기타 비디오 소스를 지령 콘솔, 비상 지휘 애플리케이션 및 기타 SIP 기반 통신 워크플로에 통합할 수 있습니다.

상호 운용성 계층이 필요한 이유

기존 감시 플랫폼과 통합 커뮤니케이션 시스템은 서로 다른 운영 목표를 중심으로 설계됩니다. 감시 측은 카메라 구성, 라이브 비디오 액세스 및 대량의 모니터링 리소스 관리에 중점을 둡니다. 통신 측은 통화, 지령 작업 및 사용자와 단말기 간의 실시간 상호 작용에 중점을 둡니다.

GB28181은 감시 네트워킹을 위한 표준화된 프레임워크를 제공하며, 비디오 리소스가 여러 지역이나 행정 수준에 분산되어 있을 때 특히 유용합니다. GB28181 플랫폼은 장치 디렉토리를 유지 관리하고 대량의 카메라, NVR 채널 및 기타 비디오 리소스를 구성할 수 있습니다.

SIP 기반 통신 플랫폼은 다른 서비스 모델을 사용합니다. SIP 단말기는 일반적으로 호출 가능한 통신 엔드포인트로 취급됩니다. 지휘관이 엔드포인트를 선택하면 시스템은 SIP 시그널링 프로세스가 세션을 설정할 것으로 기대합니다. GB28181 감시 플랫폼에서 관리하는 카메라는 이 형식으로 통신 시스템에 자동으로 제공되지 않습니다.

이러한 차이는 비상 지휘 및 융합 통신 프로젝트에서 실질적인 문제가 됩니다. 운영자는 이미 전화, 지령 단말기 및 기타 SIP 사용자에 액세스할 수 있지만 라이브 감시 비디오는 별도의 모니터링 플랫폼 내에 격리되어 있습니다. 상호 운용성 메커니즘이 없으면 두 시스템 간 전환은 운영 단계를 추가하고 통신 및 비디오 정보를 하나의 워크플로에 결합하는 기능을 제한합니다.

두 시스템 간에 직접 소프트웨어 인터페이스를 개발하는 것은 가능하지만 상당한 프로토콜 적응, 미디어 처리 및 호환성 테스트가 필요할 수 있습니다. 전용 게이트웨이는 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 간의 트랜스코딩을 제공할 수 있습니다. 이를 통해 카메라는 감시 네트워크에 적합한 인코딩 모드를 계속 사용하면서 수신 통신 시스템은 디코딩할 수 있는 스트림을 얻을 수 있습니다.

코덱 변환은 미디어 적응의 일부일 뿐입니다. 다른 엔드포인트는 해상도, 프레임 속도 및 비트레이트에 대해 다른 요구 사항을 가질 수도 있습니다. 감시 카메라는 고품질 녹화용으로 구성될 수 있지만 동일한 스트림은 제한된 네트워크를 통해 작은 지령 창에 표시될 때 불필요하게 요구가 많을 수 있습니다.

이러한 미디어 매개변수를 적응시킴으로써 게이트웨이는 수신 시스템에 더 적합한 스트림을 생성할 수 있습니다. 이는 비디오가 다른 단말기 유형에 배포되거나 통신 링크의 사용 가능한 대역폭이 다를 때 특히 가치가 있습니다.

목표는 단순히 비디오 품질을 낮추는 것이 아닙니다. 목적은 감시 소스를 수신 애플리케이션의 기능 및 운영 조건과 일치시켜 비디오가 통신 워크플로 전반에 걸쳐 사용 가능한 상태를 유지하도록 하는 것입니다.

하나의 비디오 소스로 여러 애플리케이션 서비스 가능

비디오 통합은 종종 단일 SIP 통화를 넘어 확장됩니다. 비상 지휘 센터, 브라우저 애플리케이션, 대형 화면 시각화 시스템 및 타사 비즈니스 플랫폼이 모두 동일한 감시 리소스에 액세스해야 할 수 있습니다.

이러한 이유로 GB28181 to SIP 게이트웨이는 미디어 배포 지점으로도 작동할 수 있습니다. GB28181 연결성 및 SIP 지향 통합 외에도 미디어 계층은 다음과 같은 일반적인 스트리밍 형식 및 프로토콜을 제공할 수 있습니다:

• FLV 호환 가능한 웹 및 스트리밍 애플리케이션용.

• HLS HTTP 기반 비디오 배포용.

• WebRTC 저지연 브라우저 기반 통신 시나리오용.

• RTMP 스트리밍 및 퍼블리싱 워크플로용.

• RTSP 기존 실시간 스트림 액세스가 필요한 애플리케이션용.

• GB28181 업링크 비디오 리소스가 표준 기반 감시 계층 구조에 계속 참여해야 하는 경우.

여러 출력 옵션은 모든 애플리케이션에 대해 별도의 변환 시스템을 배포해야 하는 필요성을 줄입니다. 단일 감시 리소스를 기존 비디오 환경에서 획득한 후 수신 플랫폼의 요구 사항에 따라 다른 형태로 전달할 수 있습니다.

이는 동일한 사건이 지령 콘솔, 브라우저 기반 애플리케이션 및 대형 시각화 화면에서 동시에 볼 수 있는 지휘 센터 프로젝트에서 특히 유용합니다. 게이트웨이는 각 하위 시스템에 대해 독립적인 카메라 연결을 재구축하는 대신 공통 미디어 통합 계층을 제공할 수 있습니다.

모바일 비디오를 지휘 센터로 가져오기

동일한 미디어 게이트웨이 아키텍처는 영구적으로 설치된 CCTV 카메라를 넘어 확장할 수 있습니다. 비상 운영은 기존 감시 리소스와 결합해야 하는 임시 및 모바일 비디오 소스를 자주 사용합니다.

예로는 드론, 휴대용 감시 카메라 및 바디 마운트 녹화 장치가 있습니다. 이러한 소스는 사건 현장에 임시로 배포될 수 있으며 고정 카메라가 포착할 수 없는 정보를 제공할 수 있습니다.

통합 미디어 액세스 계층을 통해 이러한 스트림을 기존 감시 카메라와 함께 지휘 워크플로에 도입할 수 있습니다. 그러면 운영자는 각 장치 범주에 대해 별도의 애플리케이션을 여는 대신 동일한 지령 환경을 통해 다양한 소스를 볼 수 있습니다.

산업 시설의 비상 대응 시나리오를 고려해 보겠습니다. 고정 카메라는 출입구, 생산 지역 및 주변 도로의 지속적인 보기를 제공할 수 있습니다. 휴대용 카메라는 사건 근처에 배치될 수 있고, 드론은 위에서 개요를 제공합니다. 현장 요원은 웨어러블 녹화 장비를 통해 비디오를 전송할 수도 있습니다.

이러한 비디오 소스가 미디어 통합 계층을 통해 연결되면 지휘 센터는 이를 SIP 기반 통신과 결합할 수 있습니다. 지휘관은 관련 비디오 리소스를 동시에 검토하면서 요원과 통신할 수 있어 운영자가 관련 없는 시스템 간을 반복적으로 이동하도록 강요하지 않고 상황 인식을 향상시킵니다.

통합을 완전한 워크플로로 설계하기

성공적인 배포는 게이트웨이를 격리된 프로토콜 변환기로 취급하는 대신 운영 워크플로를 중심으로 설계되어야 합니다.

첫 번째 단계는 기존 비디오 리소스가 어디에서 관리되는지 식별하는 것입니다. GB28181 플랫폼이 이미 완전한 디렉토리를 제공하는 경우 플랫폼 수준 통합이 일반적으로 수백 대의 카메라를 개별적으로 연결하는 것보다 더 효율적입니다. 관련된 비디오 리소스가 소수인 경우 직접 NVR 또는 카메라 액세스로 충분할 수 있습니다.

다음 단계는 사용자가 통신 시스템에서 비디오에 어떻게 액세스할지 결정하는 것입니다. 일부 프로젝트는 지령 콘솔에 내장된 감시 이미지만 필요로 합니다. 다른 프로젝트는 SIP 비디오 통화, 브라우저 재생, 대형 화면 디스플레이 및 타사 애플리케이션 액세스를 동시에 요구합니다.

코덱 호환성도 배포 전에 확인해야 합니다. 감시 카메라에서 사용되는 인코딩을 지령 단말기, 브라우저 및 기타 수신 애플리케이션의 디코딩 기능과 비교해야 합니다. 이러한 기능이 다른 경우 모든 카메라를 변경하는 대신 트랜스코딩이 필요한 스트림에만 도입할 수 있습니다.

네트워크 용량은 비디오 적응과 함께 고려해야 합니다. 로컬 녹화에 적합한 카메라 스트림은 WAN을 통해 전송될 때 필요한 것보다 더 많은 대역폭을 소비할 수 있습니다. 따라서 해상도, 프레임 속도 및 비트레이트는 비디오가 실제로 어떻게 사용될지에 따라 계획할 수 있습니다.

마지막으로 커미셔닝은 전체 워크플로를 테스트해야 합니다. 엔지니어는 게이트웨이가 카메라 스트림을 획득할 수 있는지뿐만 아니라 권한이 부여된 SIP 사용자가 올바른 채널에 액세스할 수 있는지, 예상된 코덱이 전달되는지, 미디어 재생이 안정적인지, 필요한 외부 스트리밍 인터페이스가 올바르게 작동하는지 검증해야 합니다.

이 아키텍처가 가장 큰 가치를 더하는 곳

이 솔루션은 조직이 이미 독립적인 감시 및 통신 시스템을 보유하고 있고 완전한 플랫폼 교체 없이 함께 작동해야 할 때 특히 유용합니다.

비상 지휘 센터에서 감시 비디오는 지령 활동과 연관되어 운영자가 영향을 받은 위치를 보면서 통신할 수 있습니다. 산업 시설에서 기존 CCTV 리소스는 사건 처리 및 운영 조정에 사용되는 통신 콘솔에 도입될 수 있습니다.

다중 사이트 조직은 기존 GB28181 감시 계층 구조를 유지하면서 선택된 리소스가 중앙 통신 플랫폼에서 사용 가능하도록 할 수 있습니다. 사건이 추가 시각적 커버리지를 요구할 때 임시 비디오 소스도 도입될 수 있습니다.

주요 아키텍처 이점은 각 기존 시스템이 원래 역할을 계속 수행할 수 있다는 것입니다. 감시 플랫폼은 비디오 리소스 구성 책임을 계속 유지하고, 통합 커뮤니케이션 시스템은 SIP 통신 및 지령 워크플로 책임을 계속 유지합니다. 게이트웨이는 그 사이에 필요한 프로토콜 및 미디어 변환을 처리합니다.

결론

GB28181 to SIP 게이트웨이는 둘 다 IP 비디오를 포함하지만 다른 통신 모델을 사용하는 두 시스템 간의 연결을 위한 실용적인 방법을 제공합니다. 기존 GB28181 감시 환경에 연결하고, 카메라 및 NVR 리소스를 획득하고, 선택한 비디오 채널을 SIP 액세스 가능한 엔드포인트로 변환하고, 소스와 대상이 다른 인코딩 요구 사항을 사용할 때 미디어를 적응시킬 수 있습니다.

기본 프로토콜 변환 외에도 H.264 및 H.265 트랜스코딩, 프레임 속도, 비트레이트 및 해상도 조정 지원은 감시 장치와 통신 애플리케이션 간의 실제 호환성 문제를 해결하는 데 도움이 됩니다. FLV, HLS, WebRTC, RTMP, RTSP 및 GB28181과 같은 출력을 통해 동일한 비디오 리소스를 더 넓은 범위의 지휘 및 시각화 애플리케이션에 제공할 수도 있습니다.

비상 지휘 및 융합 통신 프로젝트의 경우 게이트웨이의 가치는 두 프로토콜을 연결하는 데 국한되지 않습니다. 더 중요한 역할은 고정 카메라, NVR 리소스 및 모바일 비디오 소스가 SIP 기반 통신과 동일한 운영 워크플로에 참여할 수 있도록 재사용 가능한 비디오 상호 운용성 계층을 만드는 것입니다.

FAQ

게이트웨이 도입 시 기존 비디오 관리 플랫폼을 교체해야 합니까?

일반적으로 그렇지 않습니다. 통합은 기존 감시 계층 구조를 중심으로 설계될 수 있어 현재 플랫폼이 카메라를 계속 관리하면서 선택된 리소스가 게이트웨이를 통해 다른 시스템에 노출되도록 할 수 있습니다.

감시 사용자와 통신 사용자의 액세스 권한을 다르게 유지할 수 있습니까?

주변 플랫폼에 따라 별도로 설계할 수 있습니다. 프로젝트는 전체 감시 디렉토리를 모든 통신 사용자에게 자동으로 노출하는 대신 통합 계층을 통과할 수 있는 비디오 리소스를 정의해야 합니다.

모든 비디오 스트림을 트랜스코딩해야 합니까?

반드시 그렇지는 않습니다. 트랜스코딩은 소스 인코딩을 수신 엔드포인트에서 디코딩할 수 없거나 원본 미디어 매개변수가 대상 네트워크 또는 애플리케이션에 적합하지 않을 때 가장 유용합니다. 불필요한 변환을 피하면 처리 요구 사항을 줄일 수 있습니다.

비디오가 웹 애플리케이션에 표시되어야 할 때 게이트웨이를 사용할 수 있습니까?

예, 선택한 게이트웨이 아키텍처가 WebRTC, HLS 또는 FLV와 같은 웹 호환 미디어 출력을 제공하는 경우 가능합니다. 최종 선택은 지연 시간, 브라우저 호환성 및 애플리케이션 설계 방식에 따라 달라집니다.

대규모 카메라 디렉토리를 연결하기 전에 무엇을 테스트해야 합니까?

다른 코덱과 일반적인 비디오 프로필을 포함한 대표적인 카메라 채널을 먼저 검증하는 것이 좋습니다. 이는 통합이 훨씬 더 큰 리소스 디렉토리로 확장되기 전에 시그널링, 디코딩 및 네트워크 호환성 문제를 드러낼 수 있습니다.