Unreal Pixel Streaming ( WebRTC )

1. WebRTC

# WebRTC ( Web Realtime Communications ) 는 웹브라우저 간에 플러그인의 도움없이 서로 통신할 수 있도록 설계된 오픈소스 프로젝트로서 모바일, TV, PC가 모두 하나의 플랫폼에서 Real-Time으로 통신하는것을 목표로 한다.

음성 및 영상통화, P2P 파일과 같은 데이터 공유뿐아니라 게임 스트리밍에도 활용이 가능하도록 지원되는 기술을 말한다.

2. WebRTC 의 Architecture Overview

# 웹 애플리케이션들이 가장 상단 Web API를 통해 들어오게 된다 여기서 커넥션을 맺고 밑에 세션 관리하는 계층을 통해서 보이스 엔진과 비디오 엔진을 통해 압축된 데이터들의 잡을 제거하고 서로 주고 받게 된다. 여기서 다룰 내용에서는 WebRTC에서 데이터를 통신하는데 사용하는 Transport 레이어를 자세하게 살펴보겠다 하단에는 각 레이어 별 설명이다

Web App

실시간 통신을 위한 웹 API에 의해 작동되는 비디오, 오디오 채팅 기능을 가진 웹 기반의 3rd-party 애플리케이션

Web API

웹 기반으로 만든 화상 채팅 같은 애플리케이션을 만드는 3rd-party 개발자들에 의해 사용되는 API

WebRTC Native C++ API

브라우저 제작자가 쉽게 Web API 명세를 구현할 수 있게하는 API 레이어

Transport / Session

XMPP/Jingle 프로토콜을 사용하거나 필요로 하지 않고 libjingle의 컴포넌트들을 재사용을 통해 session 컴포넌트들이 만들어졌다.
(XMPP는 메시징 프로토콜, Jingle은 XMPP가 VoIP 요청이나 파일 전송 수립에 사용하는 서브 프로토콜)

• RTP Stack
  RTP(Real Time Protocol)를 위한 네트워크 스택
• STUN/ICE
  다양한 종류의 네트워크를 아우르는 연결 수립을 위한 STUN, ICE 메카니즘을 사용하기 위한 호출을 하게하는 컴포넌트
• Session Management
  setup, management 레이저를 호출할 수 있는 추상화된 세션 레이어
  프로토콜 구현 결정이 앱 개발자에게 맡겨진다.

VoiceEngine

VoiceEngine은 사운드 카드에서 네트워크로의 오디오 미디어 체인을 위한 프레임워크이다.

• iSAC / iLBC / Opus
  • iSAC:
    VoIP와 오디오 스트리밍을 위한 광대역/초광대역 오디오 코덱
    12 ~ 52 kbps의 비트율과 함께 16 kHz나 32 kHz 샘플링 주파수를 사용한다.
  • iLBC:
    VoIP와 오디오 스트리밍을 위한 좁은 대역의 음성 부호화기(A narrowband speech codec)
    20ms 프레임을 위한 15.2 kbps 비트레이트를 사용한 8 KHz 샘플링 주파수와 30ms 프레임을 위한 13.33 kbps
    Defined by IETF RFCs 3951 and 3952.
  • Opus:
    일정하거나 가변하는(6 kbit/s ~ 510 kbit/s) 비트레이트 인코딩, 프레임 사이즈(2.5 ms ~ 60 ms)와 다양한 샘플링율(8 kHz ~ 48 kHz)을 지원한다.
    Defined by IETF RFC 6176.

A dynamic jitter buffer와 error concealment algorithm은 네트워크 jitter와 패킷 손실의 부정적인 효과들을 은폐하기 위해 사용된다.
제일 높은 음질을 유지하면서 지연을 가능한 낮게한다.

• Acoustic Echo Canceler (AEC)
  The Acoustic Echo Canceler 재생된 목소리가 다시 마이크에 들어가면서 생긴 acoustic echo를 실시간으로 없애주는 시그널 프로세싱 컴포넌트 기반의 소프트웨어이다.
• Noise Reduction (NR)
  Noise Reduction 컴포넌트는 특정 종류의 배경 소음을 제거하는 시그널 프로세싱 컴포넌트 (주로 VoIP와 관련이 있다) 기반의 소프트웨어이다.

VideoEngine

카메라부터 네트워크로, 그리고 네트워크부터 화면으로의 비디오를 위한 비디오 미디어 체인 프레임워크이다.

• VP8
  WebM project(open web media project)의 비디오 코덱이다.
  낮은 지연시간을 위해 설계되어 RTC에 적합하다.
• Video Jitter Buffer
  비디오용 동적 지터 버퍼. 지터와 패킷 손실이 전체 비디오 품질에 미치는 영향을 숨기는 데 도움을 준다.
• Image enhancements:
  예로, 웹캠으로 캡쳐한 이미지의 비디오 노이즈를 제거한다

3. RTP ( Real Time Network Transports ) Stack

# UDP 프로토콜은 브라우저에서 실시간 통신을 위한 WebRTC 의 기반으로 사용되며, WebRTC 의 모든 기능을 수행하기 위해서, 웹브라우저는 이러한 프로토콜과 서비스의 지원이 필요하다.

NAT 및 방화벽의 여러 계층을 통과하고, 각 스트림에 대한 매개 변수를 협상해서 각 계층에 전달하고, 전달되는 사용자 데이터의 암호화기능도 수행한다.

4. RTP ( Real Time Transport Protocol ) Stack

# 각 프로토콜 계층에서 주목해야 할 부분은 STUN, TURN 으로 PixelStreaming 아키텍쳐에서 각각 서버로 구현되는 핵심 요소이다.

 

● ICE : Interactive Connectivity Establishment

클라이언트와 클라이언트 또는 클라이언트와 서버간의 연결을 맺기 위한 최적의 경로를 설정해주는 프레임워크이다. 

● STUN : Session Traversal Utilities for NAT

ICE 기반하에서 최적의 경로, 주소를 찾아주는것이 STUN 서버이다.

● TURN : Traversal Using Relays around NAT

클라이언트와 클라이언트 또는 클라이언트와 서버간의 연결이 어려울 경우 데이터를 릴레이 해주는것이 TURN 서버이다.

● SDP : Session Description Protocol

멀티미디어 세션 설정 및 통신을 위한 형식을 정의하는 프로토콜입니다. SDP는 영상 및 음성 스트리밍, 온라인 회의 및 실시간 통신과 같은 멀티미디어 세션에 대한 정보를 교환하고 기술합니다. SDP는 세션의 특성, 미디어 유형, 코덱, 미디어 스트림의 위치 및 세션의 타이밍 정보를 제공하며, 다른 디바이스나 애플리케이션 간에 멀티미디어 세션을 설정하고 동기화하는 데 사용됩니다.

● DTLS : Datagram Transport Layer Security

데이터그램 기반 통신을 보안하는 프로토콜로, 전송 계층 보안 (TLS)의 데이터그램 버전입니다. DTLS는 UDP와 같은 데이터그램 프로토콜을 사용하는 응용 프로그램에 대한 보안 솔루션으로 사용됩니다. DTLS는 데이터의 기반을 이루는 데이터그램을 안전하게 전송하고, 데이터의 무결성, 기밀성 및 인증을 보장하여 중요한 정보나 멀티미디어 데이터를 안전하게 교환할 수 있도록 합니다. 주로 VoIP 통화, 온라인 게임 및 기타 실시간 통신 응용 프로그램에서 사용됩니다.

● SCTP : Stream Control Transport Protocol

데이터 신뢰성을 보장하며, 멀티스트림 및 멀티홈 기능을 지원하는 네트워크 통신 프로토콜입니다. SCTP는 연결 지향적이며 데이터 순서를 보장하며, 주로 VoIP 및 멀티미디어 스트리밍과 같은 응용 프로그램에서 사용됩니다.

● SRTP : Secure Real-Time Transport Protocol

멀티미디어 데이터의 안전한 전송을 위한 보안 프로토콜로, 실시간 통신 응용 프로그램에서 사용됩니다. SRTP는 데이터 암호화, 무결성 확인, 인증, 리플레이 방지 등을 제공하여 데이터 보안을 강화하며, 주로 VoIP 통화 및 영상 채팅과 같은 실시간 통신 서비스에서 활용됩니다.

● DataChannel : 양방향 피어 데이터 전송을 위한 네트워크 채널 입니다.

● RTCPeerConnection : WebRTC 로컬 컴퓨터와 원격 피어간의 연결에 도움을 줌

5. STUN / TURN 서버의 역할

# STUN 서버는 클라이언트가 NAT 환경에 있을때 public IP 주소와 포트를 확인해서 통신이 가능하게 한다

TURN 서버는 STUN 서버를 이용할 수 없을때 TURN 서버를 통해 데이터를 주고 받는다

STUN, TURN 서버를 통해 얻은 연결 가능한 네트워크 주소들을 후보 ( Candidate ) 라고 부르고 이 모든 과정은 ICE ( Interactive Connetivity Establishment ) 라는 프레임워크 안에서 수행된다

 

1. STUN 서버

NAT환경에서는 Private IP를 별도로 가지고 있기 때문에 Peer to Peer(이하 P2P) 통신이 불가능 하다. 따라서 클라이언트는 자신의 Public IP를 확인하기 위해 STUN 서버로 요청을 보내고 서버로 부터 자신의 Public IP를 받는다. 그래서 이때부터 클라이언트는 자신이 받은 Public IP를 이용하여 시그널링을 할때 받은 그 정보를 이용해서 시그널링을 하게 한다.

다만 이 STUN으로 모든걸 해결할 수는 없는데 바로 두 Client가 같은 네트워크에 존재하고 있을때는 이것으로는 해결이 되지 않는다. 또한, NAT 환경에서는 Symmetirc NAT의 경우는 어플리케이션이 달라지면 NAT의 매핑테이블이 바뀔 수 있기 때문이다.

 

2. TURN 서버

TURN 서버는 클라이언트들이 통신할 때 Public 망에 존재하는 TURN 서버를 경유하여 통신하게 된다.

클라이언트는 자신의 Private IP가 포함된 TURN 메세지를 턴서버로 보낸다. 그러면 TURN 서버는 메세지에 포함된 Network Layer IP 주소와 Transport Layer의 UDP 포트 넘버와의 차이를 확인하고 클라이언트의 Public IP로 응답하게 된다. 이때 NAT는 NAT 매핑테이블에 기록되어 있는 정보에 따라서 내부 네트워크에 있는 클라이언트의 Private IP 로 메세지를 전송한다.

6. Web Signaling Server

# Signaling 은 2개의 엔드포인트 간의 위치 ( IP ) 정보 및 미디어포맷 ( SDP ) 을 전달하고 서로 P2P통신을 위해 연결을 중개하는 역할이며 Web Signaling 서버는 WebRTC 의 가장 핵심요소이다.

Media Data 는 암호화 ( DTLS ) 되어, SRTP/SCTP 프로토콜을 통해 데이터를 전송한다.