IP 비디오 전송 기술 – 4.

프로토콜 정리

다양한 프로토콜이 IP 비디오 전송에 사용되고 있으며 전송 단계의 특성에 따라 상이한 대역폭과 코덱 지원, 그리고 지연 속도를 가지고 있습니다. 또한 각 IP 프로토콜의 특성에 따라 이를 지원하는 하드웨어 장치가 달라지기 때문에 정확한 스펙을 이해한 후 시스템을 구축해야 합니다.

■ RTSP (Real Time Streaming Protocol)

RTSP는 1996년 IETF에 의해 제안된 온라인 비디오 스트리밍을 위한 프로토콜입니다.

이 프로토콜은 엔터테인먼트 및 통신 시스템에 사용되는 스트리밍 서버를 제어하도록 설계되었습니다. RTSP 서버는 라이브 스트림과 뷰어 사이에 위치하여 “재생”, “일시 중지”및 “녹화”명령을 내립니다.

RTSP가 서버 대 클라이언트 연결을 제어할 때 주문형 비디오 스트림이 사용됩니다. 클라이언트 대 서버 연결을 제어할 때 RTSP는 음성 녹음 스트림을 활용합니다. RTSP는 일반적으로 CCTV 또는 IP 카메라에서 오는 것과 같은 인터넷 프로토콜 (IP) 카메라 스트리밍에 사용됩니다.

RTSP는 “Pull” 프로토콜이며 일반적으로 컴퓨터의 뷰어가 VLC와 같은 응용 프로그램을 사용하여 스트림을 볼 때 사용됩니다. 이 경우 콘텐츠를 항상 준비 및 사용할 수 있지만(활성 스트리밍인 경우) 시청 세션을 시작하고 종료하는 것은 사용자입니다. RTSP는 유니캐스트의 경우 대부분의 장치에서는 10개의 스트림으로 제한됩니다. RTSP를 선택하면 다음 파라미터를 사용할 수 있습니다.

• RTSP 스트림 이름 – 단일 장치가 이름 포트 번호에 여러 스트림을 표시하는 경우 각 장치에 고유한 스트림 이름이 있어야 합니다.

• RTSP 포트 – RTSP 스트리밍은 HELO로 들어오는 TCP 연결을 통해 수행됩니다. RTSP 포트 슬라이딩 컨트롤을 사용하여 수신 연결을 설정할 포트를 지정합니다. 사용되는 기본 포트 번호는 554입니다.

• RTSP 인증 – 없음(사용자 이름 또는 암호 없음), 기본(사용자 이름 및 암호, SSL과 함께 사용되지 않는 한 안전하지 않음) 또는 다이제스트(사용자 이름 및 암호, 안전하게 암호화됨) 중에서 선택합니다.

• RTSP 사용의 장점 :

▪ 분할된 스트리밍 : 시청자가 전체 동영상을 시청하기 전에 다운로드 하도록 하는 대신 RTSP 스트림을 사용하면 다운로드가 완료되기 전에 콘텐츠를 시청할 수 있습니다.
▪ 사용자 정의 : 전송 제어 프로토콜 (TCP) 및 사용자 데이터 그램 프로토콜 (UDP)과 같은 다른 프로토콜을 활용하여 자신 만의 비디오 스트리밍 애플리케이션을 만들 수 있습니다.

• RTSP 사용의 단점 :

▪ 비주류 : 다른 비해 RTSP는 훨씬 덜 인기가 있습니다. 대부분의 비디오 플레이어 및 스트리밍 서비스는 RTSP 스트리밍을 지원하지 않으므로 브라우저에서 스트림을 브로드 캐스트하기가 더 어렵습니다. RTSP 스트림을 브로드캐스트 하려면 별도의 RTSP 라이브 스트리밍 서비스를 사용해야 합니다.
▪ HTTP 비호환 : RTMP와 마찬가지로 HTTP를 통해 RTSP를 직접 스트리밍 할 수 없습니다. 이로 인해 웹 브라우저에서 RTSP를 스트리밍하는 쉽고 직접적인 방법이 없습니다. RTSP는 기업 내 보안 시스템과 같은 사설 네트워크에서 비디오 스트리밍을 위해 더 많이 설계되었기 때문입니다. 그러나 웹 사이트에 포함된 추가 소프트웨어를 사용하여 RTSP를 스트리밍 할 수 있습니다.
▪ 포트 사용 제약 : 특정 포트를 사용해야 하므로 클라이언트측 포트가 방화벽에 의해 막힌 경우 방화벽을 열어야만 재생이 가능합니다.

■ RTMP (Real Time Messaging Protocol)

RTMP는 Macromedia (현재 Adobe 소유)에서 개발하였으며 지연 시간이 짧은 주문형 콘텐츠를 효율적으로 스트리밍합니다. RTMP는 인터넷을 통해 멀티미디어 파일을 이동하는 표준화된 방법입니다.

이 데이터는 미리 녹화되거나 라이브 스트리밍 될 수 있지만 RTMP는 오늘날 라이브 스트리밍 콘텐츠에 가장 일반적으로 사용됩니다.

RTMP는 Dacast, Brightcove 및 Wowza와 같은 대부분의 주요 라이브 스트리밍 플랫폼 에서 주요 옵션으로 제공되는 매우 인기있는 스트리밍 프로토콜이며 일반적으로 CDN에 콘텐츠를 전달하는데 사용되는 “푸시” 프로토콜입니다.

• RTMP 포트 요구 사항 : 기본적으로 RTMP 스트리밍을 위해 포트 TCP 1935에서 송신 연결이 이루어집니다. RTMP URL에는 다른 포트 번호를 지정할 수 있습니다.

• RTMP 사용의 장점

▪ 낮은 대기 시간 : 낮은 대기 시간을 통해 인터넷 연결이 불안정하더라도 라이브 비디오 스트림이 시청자를 위한 안정적인 연결 및 비디오 피드를 유지할 수 있습니다. 이렇게 하면 시청자가 인터넷 연결이 불안정한 상태에서 동영상을 볼 때 ‘지연’이 줄어들어 인터넷 연결이 안정되면 스트림을 빠르게 재개할 수 있습니다.

▪ 적응 가능 : 적응 가능한 피드는 시청자가 한 방향으로 피드를 시청하는데 고정되어 있지 않음을 의미합니다. 적응성을 통해 피드의 일부를 건너 뛰고 되감거나 시작된 후 실시간 스트림에 참여할 수 있습니다.

▪ 유연성 : RTMP를 사용하면 다양한 미디어 유형을 하나의 응집력 있는 패키지에 통합하여 오디오, 비디오 및 텍스트를 원활하게 혼합 할 수 있습니다. 또한 MP3 및 AAC 오디오 스트림을 모두 스트리밍하거나 MP4, FLV 및 F4V 비디오를 스트리밍하는 것과 같이 다양한 미디어 채널을 사용할 수 있습니다.

• RTMP 사용의 단점 :

▪ HTML5에서 지원되지 않음 : RTMP는 더 이상 사용 되지 않는 형식인 Flash 플레이어에서 지원됩니다. HTML5 플레이어는 빠르게 표준이 되고 있지만 RTMP는 HLS와 같은 변환기 없이는 HTML5 플레이어에서 재생할 수 없습니다.

▪ 대역폭 문제 : RTMP 스트림은 특히 낮은 대역폭 문제에 취약 할 수 있습니다. 이로 인해 시청자의 경험을 망칠 수 있는 빈번하고 실망스러운 스트림 중단이 발생할 수 있습니다.

▪ HTTP 비호환 : HTTP 연결을 통해 RTMP 피드를 직접 스트리밍 할 수 없습니다. 웹 사이트에서 RTMP 스트림을 사용하려면 Flash Media Server와 같은 특수 서버에 연결하고 타사 CDN (콘텐츠 전송 네트워크)을 사용해야합니다.

▪ 스트리밍 서버 요구 : RTMP는 특정 서비스를 제공하는 미디어 전용의 스트리밍 서버가 구축되어 있어야만 서비스가 가능하기 때문에 별도의 구축 비용이 발생합니다.

▪ HEVC/H.265 지원 안됨 : 차세대 비디오 전송 코덱으로 사용되는 H.265와 HEVC에 대한 지원이 공식적으로 불가능합니다. 다만, 외부 플러그인과 FFMPEG 프로그램을 사용하여 구축하는 사례는 있습니다. 이는 2020년을 끝으로 Adobe에서 RTMP에 대한 지원을 종료했기 때문에 공식으로 HEVC 지원이 들어갈 시간이 없었기 때문이기도 합니다.

■ SRT (Secure Reliable Transport)

SRT는 2012년 Haivision에 의해 제안되었으며, 2017년 오픈 라이선스로 전환하면서 소스코드가 공개된 완전 공개용 IP 스트리밍 전송 프로토콜입니다.

간단히 TCP(Transmission Control Protocol)의 안정성과 UDP(User Datagram Protocol) 저지연의 장점만을 갖춘 전송 기술이라고 생각할 수 있으며, 패킷 손실, 지터 및 대역폭 변동을 조정해 비디오의 신뢰성과 품질을 유지합니다. SRT를 사용하면 비디오 스트림을 예측불허의 인터넷 네트워크 환경에서도 안정적으로 실시간 영상 전송이 가능합니다.

또한 외부 네트워크에서 내부 네트워크로 비디오 전송시, 고질적인 문제점이었던 방화벽도 쉽게 우회할 수 있는 특성을 가지고 있습니다.

SRT의 컨셉은 어떤 비디오 전송과 네트워크에 상관없이 비디오 전송의 품질을 높이고, 저지연을 유지하는 것에 중점을 두며, AES 암호화로 보안을 높이고, FEC 또는 ARQ로 패킷 손실을 보상하는 것입니다.

UDP와 SRT 전송 비교, SRT를 사용할 경우 패킷 손실 없이 실시간 비디오 전송이 가능합니다

• SRT 작동 방식
제어 및 패킷 복구를 위한 전용 통신 링크가 SRT 소스(인코더)와 SRT 대상(디코더) 사이에 설정됩니다. 대상은 서버, CDN 또는 다른 SRT 장치 일 수 있습니다. SRT는 네트워크를 통해 UDP 패킷을 사용하는 자체 패킷 손실 복구 방법을 사용하므로 변동하는 네트워크 조건에 맞게 조정할 수 있습니다. 네트워크 조건이 열악하면 더 많은 패킷 버퍼링을 추가하여 비디오 품질을 향상시킬 수 있습니다. 네트워크 상태가 개선되면 거의 실시간 라이브 스트림 환경에서 지연 시간을 줄일 수 있습니다.

SRT 소스 장치와 대상 사이의 모든 방화벽을 통과해야 합니다. SRT에는 Rendezvous와 Caller / Listener의 세 가지 모드가 있습니다.

랑데부 모드는 가장 단순하며 일반적으로 SRT 소스와 대상 간에 방화벽을 통과하기 위해 IT가 관여할 필요가 없습니다. 방화벽을 통과 할 수 없으면 Caller / Listener 모드를 사용해야합니다. 그러나 대상 장치의 공용 IP 주소 및 SRT 포트에서 수신된 트래픽이 로컬 네트워크의 장치로 전달되도록 트래픽 전달을 설정하려면 일부 IT 관련이 필요합니다.

• SRT가 요구되는 분야

SRT는 원격지에 있는 기자가 현장에서 실시간으로 진행하는 레포트를 프로덕션으로 전송하기 위해 안정성을 예측하기 힘든 인터넷을 사용해야 하는 경우 탁월한 성능을 발휘합니다. 대기 시간이 짧은 인터뷰 및 양방향 대화를 위해 원격 게스트를 초대하는데도 좋습니다. 예측할 수 없는 네트워크를 통한 고품질 비디오 및 오디오가 필요할 때마다

SRT는 모든 Zoom 통화, WebEx 또는 WebRTC 스트림의 품질을 능가합니다.

신호가 한 장소에서 다른 장소로 전송될 때마다 비트 오류 및 패킷 손실의 영향을 받습니다. 고품질 비디오 신호의 경우, 이러한 네트워크 장애는 인터넷을 통해 일반 손실률도 뚜렷한 이미지 저하를 초래할 수 있습니다. 관리되지 않은 네트워크 (인터넷)에서 높은 대역폭, 낮은 레이턴시의 비디오 스트림을 전송하기 위해서는 대량의 패킷 지연 변동 (지터)을 처리하고 전송시 손실된 패킷 (패킷 손실)를 복구하는 것이 필요합니다. SRT는 이러한 문제를 해결하기 위해 제시되는 하나의 방법입니다.

• SRT 사용의 장점

▪ 우수한 전송 품질 : 전달되는 데이터가 예기치 않게 바뀌거나 패킷이 손실될 경우 Ack/Nak에 의한 재전송 요구를 통해 패킷의 손실을 막으며 이론상 10%의 네트워크 손실에도 화면이 깨지지 않는 특성을 제공합니다.

▪ 저지연 : SRT는 RTMP가 가지고 있던 저지연 특성을 그대로 유지하고 있으면서도 RTMP의 고질적인 문제였던 장시간 연결시 레이턴시가 늘어나는 문제를 해결하였습니다.

▪ 방화벽 친화적 특성 : SRT는 특정 포트가 아닌 자유로운 포트 지정이 가능하기 때문에 보안을 위한 별도의 설정 없이도 고품질의 스트리밍이 가능합니다.

▪ 강화된 보안 : 128/256 비트 AES 암호화로 앤드투앤드 콘텐츠 전송시 가장 안전한 수준으로 컨텐츠 보호가 가능합니다.

• SRT 사용의 단점

▪ 지원 플랫폼 미비 : 아직까지 최신의 전송 기술이기 때문에 미디어 스트리밍 플랫폼에서 지원하지 않는 경우가 많으며, 지원되는 하드웨어 인코더 / 디코더의 종류가 아직 많지 않습니다. Haivision의 Makito X, KB 시리즈와 AJA의 Bridge Live, DVNEST의 ProSRT 시리즈는 모두 SRT 프토로콜의 인코딩과 디코딩을 지원하고 있습니다.

▪ 재생 컨트롤 문제 : SRT는 아직까지 배속 재생이나 빨리감기, 되감기, 특정 구역 재생과 같은 재생 컨트롤을 네이티브로 지원하지 않습니다. 따라서 SRT는 First mile–Contribution에서 사용하기에 최적화된 프로토콜이라 할 수 있습니다.

■ NDI (Network Device Interface)

NDI는 2016년 NewTek사에 의해 제안된 IP 전송 프로토콜의 일종으로 무(無)손실, 압축, 제로(Zero) 딜레이, 멀티캐스트를 특징으로 하는 네트워크 비디오 전송용 코덱입니다. NDI는 라이센스 비용을 지불하지 않는 공개 (Free) 버전으로 프로토콜 개발사인 뉴텍은 NDI 지원을 위한 다양한 소프트웨어를 무상으로 배포하고 있습니다.

NDI는 기존의 전문가용 비디오 전송 프로토콜이었던 SDI를 대신하여 네트워크에서 사용 가능한 형태로 제작한 것이며 따라서 ‘네트워크 디바이스 인터페이스 (Network Device Interface)’라는 의미를 갖습니다.

NDI 프로토콜은 매우 안정적으로 설계되어 있으며 수많은 네트워크 연결 비디오 장치들에 사용되고 있습니다. 전 세계적으로 100만 명 이상의 라이브 프로덕션 사용자들이 NDI를 채택하고 사용하고 있습니다.

NDI는 표준 기가비트 이더넷을 통해 실행되도록 설계되었으며 1080i HD 비디오를 VBR 데이터 전송 속도로 보통 약 100 Mbit/s로 제공합니다.

기본적으로 NDI는 mDNS(Bonjour / Zeroconf) 검색 메커니즘을 사용하여 로컬 영역 네트워크에 소스를 보급합니다. NDI 수신 장치는 이러한 소스를 자동으로 검색하고 제공할 수 있습니다. 단, 서브넷을 통한 다른 두 가지 검색 모드(NDI Access, NDI Discovery Server)는 MDNS 없이 소스를 생성합니다. NDI 송신 호스트의 포트 범위에서 임의로 선택한 TCP 포트입니다. 소스가 요청되면 NDI 수신기가 NDI 송신기에 연결되면서 해당 포트에 TCP 연결이 설정됩니다.

양방향으로 전송 가능한 멀티 캐스트 비디오 전송규격인 NDI

NDI는 비디오, 다중 채널 비압축 오디오[citation] 및 메타데이터를 제공합니다. 메타데이터 메시지는 양방향으로 전송되어 발신인과 수신인이 XML 형식의 임의 메타데이터와의 연결을 통해 서로 메시지를 보낼 수 있습니다.

이 방향 메타데이터 시스템을 통해 소스에게 피드백되는 활성 집계 정보와 같은 기능을 통해 소스들이 방송 중임을 파악할 수 있습니다(프로그램/프리뷰).

NDI는 또한 송신자가 연결된 수신자의 수를 결정할 수 있도록 허용하므로, NDI 수신기 클라이언트가 연결되지 않은 경우 불필요한 처리 및 네트워크 대역폭 활용을 건너뛸 수 있습니다. NDI 수신기는 비디오가 필요하지 않은 오디오 전용 또는 메타데이터 전용 연결과 같은 다양한 스트림 조합에 연결할 수 있습니다.

• NDI 사용의 장점

▪4K 이상의 UHD 구현 : NDI는 네트워크 압축율을 조정하여 HD ~ 8K까지 자유로운 해상도를 전송할 수 있습니다. SDI는 물리적인 전송 매체의 한계로 인해 4K 이상의 해상도를 전송하는 경우 거리 제약이 발생하며 8K와 같은 초고해상도에 대한 지원이 불가능하다는 문제가 있습니다.

▪하드웨어 없이도 구현 : NDI는 일단 어떤 형태의 영상이건 NDI 프로토콜로 한번 변환되기만 하면 네트워크 상의 데이터로 존재하기 때문에 별도의 하드웨어 없이도 일반 PC에서 모니터링과 멀티 뷰어 구축이 가능합니다. 최근 인기를 끌고 있는 eSports와 같이 원본 소스가 컴퓨터 그래픽일 경우, PC의 출력을 소프트웨어 적인 NDI 스캔 컨버터로 변환하여 NDI 소스로 만들어낼 수 있으므로 별도의 하드웨어 없이도 라이브 스트리밍과 스위칭용 소스로 만드는 것이 가능해집니다.

▪단순한 케이블링 : NDI는 IP 비디오 규격답게 단순히 비디오, 오디의 통합을 넘어서서 비디오, 오디오, 카메라 컨트롤, 탈리, 자막, 메타데이터를 공급할 수 있으며, PoE를 통한 전원 공급까지 가능합니다. NDI를 네이티브로 지원하는 PTZ 카메라를 사용하게 된다면 단순히 랜선 하나를 연결하는 것으로 카메라 컨트롤과 비디오, 오디오 전송, 전원공급까지 모두 가능해집니다.

▪SDI 라우터 대체 : NDI는 네트워크를 통해 비디오를 전송기 때문에 마치 방송국에서 지상파로 방송을 뿌리는 것처럼 여러 대의 장비로 동일한 소스를 출력하는 것이 가능합니다. 즉 하나의 NDI 입력이 네트워크에 연결되는 순간 마치 모든 NDI 장치들은 비디오 라우터에 소스가 추가된것처럼 인식하게 되므로 하나의 소스를 다른 스위쳐의 공용 소스로 즉시 사용할 수 있습니다.

• NDI 사용의 단점

▪비압축 대비 화질 열화 : NDI는 압축 알고리즘(SHQ / H.264/H.265)을 사용하기 때문에 완전한 비손실 압축을 지원하지는 못합니다. NewTek에서는 시각적 비손실 압축(Visual Lossless Compression)이라는 말로 이런 특징을 설명합니다. 하지만 오리지널 NDI 규격인 SHQ 압축은 현재 방송 제작에 널리 사용되고 있는 XDCAM 규격의 2배 이상 대역폭을 제공하므로 실제 방송 제작용으로 충분한 화질을 제공합니다.

▪인터넷을 통과하지 못함 : NDI는 mDNS 검색 기능을 통해 기기를 인식하기 때문에 기본적으로 LAN으로 구성된 내부망에서만 동작할 수 있습니다. 물론 VPN이나 클라우드를 사용해서 이를 우회하는 기술이 존재하지만 보편적으로 권장되는 것은 아닙니다.

■ HLS (HTTP Live Streaming)

HLS는 애플에 의해 2009년 제안된 라이브 비디오 스트리밍 프로토콜입니다. 별도로 고가의 스트리밍 전용 미디어 서버를 구축해야 하는 기존의 방식과 다르게 HSL는 일반 웹서버에서도 라이브 스트리밍이 가능하다는 특징을 가지고 있습니다.

HLS의 동작 원리는 단순합니다. 하나의 영상을 10초 단위로 쪼개어 재생 목록을 만든 후 이렇게 잘라진 짧은 비디오 조각을 일반적인 다운로드해서 재생하게 됩니다. 따라서 기존의 웹서버만 가지고도 라이브 비디오 스트리밍을 할 수 있는 장점을 가지게 됩니다.

• HLS 장점

▪ 기존의 웹서버를 그대로 사용 : 이는 라이브 스트리밍 서버의 구축 비용을 대폭 절감할 수 있게해주는 획기적인 기술입니다. 또한 웹서버가 사용하는 ‘80포트’를 제제하는 방화벽은 없기 때문에 더 이상 방화벽 포트 문제로 네트워크 관리자들과 씨름을 할 필요가 없게 됩니다.

▪ 뛰어난 모바일 호환성 : HLS 자체가 Apple의 iPhone에서 원활한 비디오 스트리밍을 사용하기 위해 만들어진 프로토콜인 만큼 뛰어난 모바일 호환성을 갖습니다. 현재 모든 종류의 Apple 기기(iPhone, iPad, Macbook)에서 100% 호환성을 가지며 안드로이드 모바일 기기에서도 별도의 플러그인 없이 기본 재생이 가능합니다.

• HLS 단점

▪ 30초 이상의 재생 딜레이 : HLS는 동작 원리가 10초 단위의 세그먼트로 영상을 분할해서 전송하는 기술이기 때문에 필연적으로 기본적으로 수 십 초의 딜레이가 발생하게 됩니다. 현장이 아닌 장거리 전송에서 이러한 딜레이는 아무런 문제가 되지 않습니다. 하지만 현장 전광판을 통한 재생이나 같은 장소에서 멀티 디스플레이로 상영하는 경우에 각 디스플레이별로 10초 이상의 딜레이 차이가 발생할 수 있습니다.

▪ 윈도우 PC에서 재생시 플러그인 요구 : HLS 기술이 Apple에서 시작된만큼 Mac PC와의 호환성을 우수하지만 윈도우 PC와의 호환성은 상대적으로 떨어지는 편입니다. PC에서

■ DASH (Dynamic Adaptive Streaming over HTTP)

DASH의 정식 명칭은 MPEG-DASH이며 이름에 이미 모든 기술적 정의가 포함되어 있습니다. DASH는 2011년 MPEG(Moving Picture Experts Group)에서 제안한 프로토콜로서 기술적으로 HLS와 거의 동일한 매커니즘을 가지고 있습니다.

• DASH 장점 :

▪ HTMP5 기반으로 기존 웹서버 사용 : DASH는 차세대 웹서버 표준인 HTML5를 기반으로 하기 때문에 별도의 플러그인 없이 최신의 웹 브라우저에서 자동으로 재생이 됩니다. 또한 기존의 웹서버를 사용하기 때문에 방화벽의 제한없이 사용할 수 있는 편리함을 제공합니다.

• DASH 단점 :

▪ Safari 브라우저에서 재생 불가 : 애플의 웹 브라우저인 Safari는 DASH의 재생을 허용하지 않습니다. 따라서 Safari를 기본 웹브라우저로 사용하는 iPhone, Mac, Apple TV 등과 호환성이 떨어지므로 모바일 환경에 불리하게 됩니다.
▪ 3~40초의 재생 딜레이 : HLS와 마찬가지로 10초 단위의 세그먼트로 쪼개서 전송하기 때문에 수 십 초의 전송 딜레이가 발생하며 현장 재생용 프토토콜로는 적합하지 않습니다.

■ WebRTC (Web Real-Time Communication)

WebRTC는 2011년 구글에 의해서 제안되었습니다. 대부분의 라이브 스트리밍 프로토콜들이 방송용 비디오를 전송하는 목적을 가지고 있는 것에 비해 WebRTC는 순수하게 화상회의를 목적으로 하는 프로토콜입니다.
기존의 화상회의 솔루션들은 모두 중간에서 회의 참가자들을 상호 연결시켜주는 일종의 서비스 제공자가 필요했습니다. 하지만 WebRTC는 화상회의 전용 API를 내장하여 웹 브라우저를 통해 직접 오디오와 비디오를 포착해서 자유롭게 스트리밍 전송과 데이터 전송을 가능하게 합니다.
쉽게 이해하면 P2P 데이터 전송 기술을 화상 회의 데이터 전송에 사용하는 것이라고 생각할 수 있습니다.

WebRTC는 크롬, 사파리, 익스플로러, iOS, 오페라, 모질라 등 대부분의 웹 브라우저와 호환이 가능하며, HTTPS를 강제로 적용하기 때문에 외부 공격에 대한 보안이 보장됩니다.

• WebRTC 장점

▪별도의 플러그인이 필요없는 브라우저 기반 : WebRTC는 오픈 소스를 기반으로 하고 있기 때문에 브라우저에 대한 호환성이 높으며 별도의 플러그인없이 브라우저 간에 직접 통신이 가능하다는 장점을 갖습니다.

▪ 0.5초 미만의 딜레이 : 화상회의에 최적화된 비디오 데이터 전송 방식을 취하고 있기 때문에 기존의 스트리밍 프로토콜과 비교하면 아주 짧은 딜레이만을 가지게 됩니다.

▪ HTTPS 기반 보안 : 오픈소스 규격에서부터 WebRTC는 HTTPS를 강제하고 있으며 Plaintext key 방식으로 방화벽을 통과하면서도 보안성을 유지하고 있습니다.

• WebRTC 단점 :

▪고화질 구현이 어려움 : UDP 기반으로 구현되는 WebRTC는 빠른 전송을 중요하게 생각하기 때문에 비디오 전송 과정에서 프레임이 손실되는 것을 복구하지 않습니다. 또한 UHD 등의 차세대 고화질 영상에 대한 구현도 불확실한 상태이며, FHD 전송에 대한 화질 보장도 가능하지 않습니다. 이 모든 것은 화상회의 전용으로 설계된 프로토콜이라는 한계를 명확하게 보여주는 것입니다.

▪ 화상회의 전용으로 베이스밴드 입출력에 불리 : 마찬가지로 WebRTC는 양쪽 브라우저 간에 P2P 방식으로 화상회의 데이터를 상호 교환하는 방식으로 신호를 주고받기 때문에 WebRTC를 직접 인코딩하거나 디코딩하는 하드웨어 장치의 구성이 어렵습니다. 즉, SDI나 HDMI 같은 전통적인 베이스밴드 직접 신호로 변환할 수 있는 하드웨어를 기대할 수 없게 됩니다.