Protocol_6주차_WebRTC 구조

DTLS : Datagram Transport Layer Security

TLS는 네트워크 트래픽을 보호하기 위해 가장 널리 배포된 프로토콜(투명한 연결지향 채널 제공)

응용계층과 전송계층 사이에 TLS를 삽입함으로써 응용 프로토콜을 보호하기 쉽다. 그러나 TLS는 안정적인 전송 채널(일반적으로 TCP)을 통해서 실행되어야 한다. 따라서 신뢰할 수 없는 데이터그램 트래픽을 보호하는데 사용할 수 없다.

점점 더 많은 응용 프로그램 계층 프로토콜이 UDP전송을 사용하도록 설계되었다. 특히 SIP(Session Initiation Protocol) 및 전자게임과 같은 프로토콜이 널리 보급되고 있다. (sip는 TCP, UDP 모두 실행될 수 있지만 UDP가 선호됨)

대부분의 경우 클라-서버 응용 프로그램을 보호하는 바람직한 방법은 TLS를 사용하는 것이지만 데이터그램 구조(혹은 체계)에서는 자동적으로 TLS사용을 금지한다. 

=> UDP가 DTLS를 사용하는 이유!

The basic design philosophy of DTLS is to construct "TLS over
   datagram transport".  The reason that TLS cannot be used directly in
   datagram environments is simply that packets may be lost or
   reordered.  TLS has no internal facilities to handle this kind of
   unreliability; therefore, TLS implementations break when rehosted on
   datagram transport.  The purpose of DTLS is to make only the minimal
   changes to TLS required to fix this problem.  To the greatest extent
   possible, DTLS is identical to TLS.  Whenever we need to invent new
   mechanisms, we attempt to do so in such a way that preserves the
   style of TLS.

DTLS는 DTLS가 패킷 손실과 재정렬이라는 두 가지 문제를 해결해야한다는 점을 제외하고는 의도적으로 TLS와 유사합니다. DTLS 구현

1. 패킷 재전송
2. 핸드 셰이크 내에서 시퀀스 번호 할당
3. 재생 감지.

--------------------------------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------------

When implementing WebRTC, you must consider:

 

상호 운용성 - 소비자는 밤 사이에 도구를 전환 할 수 있지만 비즈니스 시스템은 점진적 전환과 다양한 기술 세트의 공존을 지원해야합니다. 가까운 장래에 계속 사용할 SIP 전화, 소프트 폰, 화상 회의 장비 등의 대규모 설치 기반이 있습니다. WebRTC는 기존 구성 요소 중 일부를 대체하기위한 것이 아닌 새로운 기술 중 하나 일뿐입니다. WebRTC 표준은 여전히 ​​진화하고 있으며 비디오 코덱 및 중요한 대량 채택과 관련하여 여전히 불확실성이 있습니다.

성능 및 확장성 - WebRTC는 사용자 개입의 필요성을 최소화하도록 설계되었으므로 클라이언트 구현은 현재 최선의 노력으로 사용 가능한 대역폭에 적응하도록 호출 매개 변수를 자율적으로 조정하려고합니다. 비즈니스 응용 프로그램에서 일반적으로 성능 요구 사항이 엄격해지므로 응용 프로그램은 연결을 모니터링하여 수정 작업을 수행하거나 통화 품질이 저하 될 경우 관리자에게 경고해야합니다. 또 다른 중요한 질문은 확장성에 관한 것입니다. 소비자 지향 도구에 채택된 메시 토폴로지가 정답입니까? 또는 더 확장 할 수있는 MCU 기반 솔루션을 요구하는 많은 수의 사용자를 지원해야한다는 요구 사항이 있습니까?

모바일 장치 - Apple 및 Microsoft 플랫폼은 현재 WebRTC를 지원하지 않습니다. 코덱 표준 및 하드웨어 가속은 모바일 장치에서 CPU 및 배터리 사용을 최소화하는 데 중요합니다. 대부분의 모바일 SOC 및 칩셋에서 하드웨어 기반 VP8 인코딩 / 디코딩 구현이 가능 해지고 있습니다.

------------------------------------------------------------------------------------------------------------------

위의 스택은 클라이언트 장치에서 실행됩니다. 클라이언트 장치가 WebRTC를 통해 서로 통신하고 비즈니스의 다른 통신 요소와 통신하려면 다른 여러 네트워크 요소가 필요합니다.

응용 프로그램 서버 또는 웹 서버는 연결을 요청하고 미디어 매개 변수를 협상하기 위해 사용자가 등록하거나 서로를 찾을 수 있도록 응용 프로그램을 호스팅 할 수 있습니다.

STUN 및 TURN 서버는 클라이언트 브라우저 간의 피어 투 피어 미디어 연결이 NAT (Network Address Translation) 게이트웨이 및 방화벽을 통과 할 수있게하는 데 사용됩니다.

응용 프로그램이 기존 전화 통신과의 통합을 필요로하거나 통화 개시 및 제어 프로토콜로 SIP (Session Initiation Protocol)를 사용하는 경우 웹 소켓을 통해 SIP를 UDP를 통해 SIP로 변환 할 수있는 SIP 게이트웨이를 배포해야합니다.

모든 엔드 포인트가 동일한 오디오 / 비디오 코덱 집합을 사용하면 미디어 스트림이 미디어 스트림을 직접 전송할 수 있습니다. 그러나 비즈니스 응용 프로그램에서 가장 일반적인 시나리오는 다른 코덱을 사용하는 기존 엔드 포인트가 있다는 것입니다. 이 경우 트랜스 코딩을 수행하는 RTP 미디어 게이트웨이를 배포해야합니다.

------------------------------------------------------------------------------------------------------------------

**INTEROPERABILITY(상호운용성) - Media

WebRTC 표준은 규정 준수 구현에 의해 지원되는 필수 코덱을 결국 정의하지만 표준화 커뮤니티 내의 논쟁에서 여전히 주제입니다. 두 개의 주요 경쟁자는 VP8 / VP9와 H.264 / H.265입니다 (VP8과 H.264를 오늘 배포되는 가장 일반적인 버전이라고합니다).

Google은 VP8 코덱 뒤에 기술을 도입하고 오픈 소스 형식으로 구현을 발표했으며 로열티 지불을 요구하지 않겠다고 약속했습니다. H.264는 오랫동안 사용 가능한 표준으로, 어디에서나 사용할 수 있습니다 (HARDWARE 기반의 플랫폼에서의 가속화 포함). H.264와 마찬가지로 H.264는 로열티가 없다는 것입니다.

대부분의 독립형 응용 프로그램의 경우 지원되는 비디오 코덱은 그다지 관련이 없지만 기존 시스템과의 통합이 필요한 비즈니스 솔루션의 경우 코덱 선택이 트랜스 코딩의 필요성에 영향을 미칩니다.

오늘날 대부분의 WebRTC 구현은 VP8 비디오 코덱을 사용하지만 설치된 대부분의 비디오 시스템은 H.264를 사용합니다.

하나 이상의 코덱 (및 각 코덱의 다른 버전)을 지원해야 할 필요가있는 상황에서 가장 가능성있는 시나리오를 가정하면 비즈니스 응용 프로그램이나 추가 네트워크 요소가 미디어의 코드 변환을 처리하고 제공해야합니다.

미디어 트랜스 코딩에는 상당한 컴퓨팅 성능이 필요하며 이는 솔루션의 확장성을 제한 할 수 있습니다. 전통적으로 미디어 서버는 트랜스 코딩하기 위해 특정 DSP 기반 하드웨어를 사용합니다. 그러나 일반적인 고성능 CPU의 소프트웨어 기반 트랜스 코딩은 이제 점점 더 보편화되고 있습니다 (표준 클라우드 인프라를 사용하는 유연한 배포에서는 이러한 요구 사항이 필요합니다).

WebRTC는 미디어 스트림을 제어하기 위해 RTCP에 크게 의존합니다.

(예를 들어, 이미지 리프레시 요청을 위해), 많은 기존의 애플리케이션 / 디바이스가 애플리케이션 계층을 통해 (예를 들어, SIP 메시지를 통해)이를 수행하므로, 트랜스 코딩 또는 게이트웨이 엘리먼트는 이것을 또한 처리 할 필요가있다.

"웹에서의 WebRTC 배포를위한 트랜스 코딩 CPU 리소스를 예측하는 것은 프로젝트의 실행 가능성을 결정하는 데 중요합니다."

**INTEROPERABILITY–CALL SETUP AND SIGNALING

 

WebRTC는 원래 웹 응용 프로그램과의 통신 통합을 용이하게하는 기술로 정의되었습니다. 보편적인 통신을위한 도구로 사용되지 않으므로 호출 설정 및 제어를 위한 신호 계층을 포함하지 않습니다.

SIP는 통화 설정에서 전화 통신에 널리 사용됩니다. 비즈니스 커뮤니케이션 시스템과의 통합이 필요한 경우 클라이언트 간의 호출 및 요구 사항을 지원하는 비즈니스 응용 프로그램의 자연스러운 후보입니다.

SIP는 별도의 제어 네트워크를 통해 실행되도록 설계되었습니다. 웹 응용 프로그램에서 트래픽 (콜셋 설정 및 제어 포함)을 오버웨이 프로토콜로 전송하는 것이 더 편리합니다.

웹 소켓 연결로 캡슐화됩니다. 비즈니스 응용 프로그램에서 사용하는 호출 관리자가 웹 소켓을 통한 SIP를 지원하지 않으면 WebRTC SIP 게이트웨이가 필요합니다.

JsSIP 및 sipML5와 같은 오픈 소스 WebRTC 클라이언트에 포함 된 SIP 스택은 기본 세션의 구축을 지원합니다. 통화 전송, 회의 등의 추가 기능을 지원해야하는 경우,

이러한 스택의 조정이 필요합니다. SIP 구현이 얼마나 필요한지에 따라 약간의 개발 노력이 필요합니다.

응용 프로그램이 단순한 호출 기능만 제공하고 레거시 텔레포니와의 통합을 필요로하지 않는 경우 SIP 사용의 대안은 독점적인 세션 설정 프로토콜을 구현하는 것입니다. 현재 시장에 나와있는 일부 WebRTC 서비스 및 플랫폼은 이러한 접근 방식을 취해 JSON 또는 XML을 통해 간단한 신호를 생성합니다. 그러나 실제로 우리는 전형적인 비즈니스 유스 케이스가 더 완전한 통화 제어를 요구한다는 것을 발견했습니다.

SIP 기반 비즈니스 시스템과의 비 호환성 문제가 벤더에게 남아 있습니다.

**INTEROPERABILITY–BROWSERS

현재 Google 크롬, Mozilla Firefox 및 Opera 브라우저에는 WebRTC가 내장되어 있습니다.

이는 브라우저 설치 기반의 절반 이상을 차지하지만 Apple 사파리와 Microsoft Internet Explorer는 포함되지 않습니다.

애플은 입장을 밝히지 않았지만, WebRTC의 평준화 효과를 감안할 때 그렇게하지 않으면 참여하기가 쉽지 않다. Microsoft는 CU-RTC-Web과 비슷한 움직임을 보였지만 비슷한 다른 "표준"을 도입했지만 Skype를 소유하게됨에 따라 분명한 이해 관계가 상충합니다. WebRTC가 중요한 두 플랫폼 / 브라우저 플레이어의 조기 지원없이 성공하려면 주요 응용 프로그램을 얻는 것이 중요한 과제입니다.

사용자 관점에서 브라우저 간 WebRTC 구현은 이미 문제없이 상호 운영됩니다 (예 : Chrome 사용자가 Mozilla 사용자와 '대화'할 수 있음).

그러나 개발자에게는 고려해야 할 차이점이 있습니다. WebRTC 표준이 계속 진화하고 있기 때문에 API 구현은 브라우저간에 100 % 균일하지 않습니다 (예 : 공급 업체 접두어가 API 함수에 추가됨). WebRTC 개발을 탐구하는 웹 개발자에게는 이것이 큰 문제는 아니지만 adapter.js와 같은 도구와 모듈이 개발 노력을 단순화하기 위해 이러한 차이를 추상화하는 것으로 나타났습니다.

또한 WebRTC 엔진 구현의 완성도가 달라 화면 캡처와 같은 기능이 모든 브라우저에서 사용할 수있는 것은 아닙니다 (이 글을 쓰는 시점에서).

응용 프로그램 개발자는 사용자에게 깨끗한 사용자 환경을 제공하기 위해 이러한 차이점을 어떻게 처리 할 것인지 고려해야합니다.

4 WEBRTC PERFORMANCE & SCALABILITY

4.1 MONITORING MEDIA PERFORMANCE

WebRTC는 최선의 노력을 기울여 호출 매개 변수를 자율적으로 조정하는 등 사용자 개입의 필요성을 최소화하도록 설계되었습니다.

비즈니스 응용 프로그램에서 성능 요구 사항은 일반적으로 더 엄격합니다. 응용 프로그램은 연결을 모니터링하고 사용자 환경을 최적화하기 위해 미디어 스트림을 조정하거나 통화 품질이 저하 될 때 최소한 관리자에게 알립니다.

미디어 품질은 패킷 손실, 사용 가능한 대역폭 및 프레임 속도와 같은 정보를 제공하는 WebRTC GetStats API를 사용하여 모니터링 할 수 있습니다.

이를 기반으로 WebRTC 클라이언트는 다음과 같이 할 수 있습니다.

- 대역폭에 대한 SDP (Session Description Protocol) 매개 변수를 변경하여 미디어를 다시 협상하고 대역폭을 제한하십시오.

- 해상도가 낮거나 다른 제약 조건을 사용하여 다른 미디어 스트림을 요청하고 해당 미디어와 미디어를 다시 협상합니다.

모든 미디어 애플리케이션에서와 마찬가지로 시스템의 모든 인라인 구성 요소 (예 : TURN 릴레이 서버 또는 미디어 게이트웨이)의 성능은 연결의 성능과 품질 및 궁극적으로 사용자 환경에 영향을 미칠 수 있습니다. 우리는 예기치 않은 품질 문제로 이어질 수있는 TURN 서버 성능의 놀라운 차이를 발견 했으므로 이 요소를 선택할 때 높은 수준의 주의를 기울일 것을 권장합니다. 

0. 4.2 DO I NEED AN MCU?
   

WebRTC 디자인 가정은 미디어 스트림이 중개를 필요로하지 않고 피어 - 투 - 피어 (peer-to-peer)로 직접 이동한다는 것입니다. 다중 사용자 애플리케이션의 경우 이는 각 참여자가 다른 모든 참여자와 상호 작용하고 서로 다른 참가자에게 오디오 스트림을 보내고받는 "메쉬"토폴로지를 의미합니다. 이는 네트워크 인프라의 필요성을 줄이고 대기 시간을 최소화하는 데는 탁월하지만 모든 종단점에 같은 코덱을 사용하고 유사한 기능을 요구합니다.

메시 토폴로지는 모든 노드가 다중 스트림의 오디오 / 비디오를 처리해야하기 때문에 각 노드의 CPU 및 대역폭 요구 사항이 통화 당사자의 수에 따라 기하 급수적으로 증가합니다. 이것이 순수한 WebRTC (또는 Skype와 같은 다른 소비자 지향적 인 응용 프로그램)가 소수의 당사자 이상으로 확장 할 수없는 이유입니다.

일부 응용 프로그램에서 작동하는 하나의 대체 접근 방식은 노드 중 하나를 선택하여 오디오 스트림을 믹싱하고 단일 비디오 스트림을 작성하여 서로 다른 클라이언트로 전송하는 작업을 수행하는 것입니다. 그러나 중앙 노드의 CPU 및 대역폭 요구 사항은 통화 당사자의 수에 비례하여 증가합니다. 이로 인해 혼합을 수행하는 노드를 선출하고 해당 노드의 실패를 처리하는 것과 같은 다른 복잡성이 발생합니다

비즈니스 응용 프로그램은 서로 다른 코덱을 사용하고 다른 기능 (화면 크기, 데이터 및 기타 기능)을 사용하여 더 많은 사용자를 요구할뿐만 아니라 이기종 종단점 세트 (예 : IP 전화, 소프트 폰, 회의실 화상 회의 시스템 등) 기타.). 많은 응용 프로그램은 모든 오디오 및 비디오 스트림의 처리를 중앙 집중화하는 MCU (Multipoint Control Unit)를 구현합니다.

Conference Bridge라고도하는 MCU는 다중 지점 화상 회의 시스템의 중앙 게이트웨이입니다. 역사적으로 MCU는 실시간으로 오디오 / 비디오를 처리 할 수있는 특수 DSP 기반 하드웨어가 필요했지만 이제는 표준 하드웨어 및 클라우드 환경에서 실행되는 소프트웨어로 MCU를 완전히 구현할 수 있습니다.

다음 다이어그램은이 세 가지 대안에 대한 요약과 비교를 제공합니다. 귀하의 유스 케이스는 어떤 옵션이 귀하에게 적합한지를 지시합니다.

5 WEBRTC – MOBILE

모바일 장치 앞면에서는 WebRTC가 Chrome, Mozilla 및 Opera에서 Android에서 지원되지만 Apple IOS 및 Microsoft Windows에서는 WebRTC에 대한 기본 브라우저가 지원되지 않습니다.

IOS 및 Windows 장치에서 WebRTC 응용 프로그램의 모바일 구현을 위해 기본 브라우저 지원 대신 WebRTC 엔진 기능을 제공하는 SDK / 라이브러리를 활용하고 응용 프로그램 개발을 허용하는 API를 제공합니다.

오늘날 매우 중요한 또 다른 주요 과제는 VP8 비디오 미디어를 인코딩 / 디코딩 할 때 발생하는 CPU 및 배터리 소모량 (모바일 엔드 포인트)입니다. H.264의 인 코드 / 디코드는 여러 해에 걸쳐 모바일 칩셋에서 지원되지만, V8을 지원하지는 않습니다. CPU에서 VP8 또는 다른 미디어 형식 인코딩 / 디코딩은 성능 저하 및 배터리 소모를 초래하는 중대한 프로세스입니다.

위의 그래프는 Rockchip RK2918 기반의 안드로이드 타블렛에서 VP8 디코딩 성능의 전력 소비 영향을 보여줍니다.

VP8의 하드웨어 인코딩 / 디코딩을 지원하는 새로운 SoC (System on a Chip) 구현이 점차 가능 해지고 있습니다. 몇 가지 예 :

•  Qualcomm Snapdragon 800 
•  nVidia Tegra 4 
•  ST-Ericsson NovaThor LT9540 
•  Intel Z3480
  예를 들어 Google Nexus 5, Samsung Note 및 Galaxy 인 Sony Experia를 비롯한 최신 휴대 전화 및 태블릿은 이미 VP8을 하드웨어로 지원합니다.

------------------------------------------------------------------------------------------------------------------

SFU방식은 미디어 스트림을 릴레이해야되기 때문에 추가적인 레이턴시가 생긴다. 하지만 cpu사용량과 필수적인 uplink 대역폭이 상당히 감소한다. 단점은 모든 리시버가 똑같은 퀄리티의 스트리을 받는다. 

=> 스트림을 변경하지 않고(즉, 서버에서 트랜스코딩=압축을 하지않으므로) 그대로 리시버에게 전송하기 때문에 더 큰 네트워크 대역폭이 필요. 레이턴시도 생김? 압축안하면 더 빨라야하는거 아닌가? 아님 더 많은 데이터를 보내기 때문에 레이턴시가 증가?

SFU와 비교하여, MCU는 수신 된 비디오 스트림을 상이한 품질로 전송하는 능력을 가지며, 예를 들어, 두 명의 동료가 VP8 ~ H264를 사용하지 않을 때

동일한 비디오 코덱을 지원합니다.

WebRTC gateway

WebRTC 게이트웨이는 WebRTC 메쉬 된 호출과 비교하는 데 사용됩니다.

섹션 3-2-2에서 설명한 것처럼 스트림을 다른 모든 클라이언트로 전달하는 SFU와 이러한 스트림을 단일 스트림으로 수신기로 전송하기 전에 추가로 처리하고 다중화하는 MCU의 두 가지 변종을 사용할 수 있습니다. 이 섹션에서는 세 가지 솔루션에 대해 설명합니다.

• Jitsi Videobridge, recently acquired by Atlassian, offers a SFU solution which relays the streams to all call participants. 

• Janus WebRTC Gateway, also offers this same SFU solution and has additional support for extra custom plugins which allow e.g. MCU-like functionalities 

• Kurento, is a media server offering MCU-like capabilities such as transcoding, multiplexing and recoding. Unfortunately, Kurento is not commercially used due to its extreme licensing which prevents this

다중 사용자 성능 분석을 위해 Janus 게이트웨이가 사용됩니다. Janus가 Kurento보다 더 널리 사용되는 이유는 상용 회사가 라이센스를 부여하기 때문입니다.

그것을 자유롭게 사용할 수 있습니다. Jitsi Videobridge는 기본적으로이 기능을 제공하지 않지만 Janus 게이트웨이는 성능 분석에 필요한 호출 특성을 출력하므로 Jitsi 대신 Janus가 선택됩니다. 추가적인 복잡성을 피하고 더 나은 것을 피하기 위해

재현성, 성능 분석의 테스트는 Janus SFU로 제한되며 MCU WebRTC 솔루션은 분석되지 않습니다.

Interoperability

W3C (World Wide Web Consortium)와 IETF (Internet Engineering Task Force)는 서로 다른 브라우저 공급 업체가 서로 통신 할 수 있게 하는 WebRTC의 표준을 만들기 위해 열심히 노력하고 있습니다. 작성 시점에 모든 브라우저가 WebRTC를 지원하지는 않지만 여러 브라우저가 서로 다른 코덱을 지원하고 모바일 장치에 대한 지원도 다양합니다.

이 장에서는 WebRTC의 다양한 구현 및 상호 운용성에 대해 설명합니다.

이 장에서는 4-1 절의 WebRTC의 현재 적용 범위를 살펴 봅니다.

그런 다음 서로 다른 오디오 및 비디오 코덱에 대해 논의하고 섹션 4-2에서 서로 다른 방식으로 작업합니다. 4-3 절에서 다른 브라우저 구현이 이어지고 마지막으로 4-4 절에서 모바일 지원이 논의됩니다.

4-1 Adoption

WebRTC는 비교적 새로운 기술이지만, 대부분의 주요 인터넷 브라우저는 그림 4-1과 같이 프로토콜을 부분적으로 지원합니다.

녹색은 완전한 지원을 나타내며, 노란색은 부분 지원을 나타내고 빨간색은 지원이 표시되지 않습니다.

이 스크린 샷은 조정되었으며 WebRTC 호출을 설정하는 데 중요한 구성 요소와 몇 가지 기능에 대해 설명합니다.

그림 4-1은 브라우저가 지원하는 다양한 비디오 코덱을 보여 주며 Internet Explorer <= 11 및 Safari는 WebRTC의 기능을 지원하지 않습니다.

이에 대해서는이 장의 나머지 부분에서 자세히 설명합니다.

브라우저 지원은 한 가지 사항이지만,이 브라우저의 사용법을 고려하는 것이 더 흥미 롭습니다.

따라서이 논문은 Net Market Share [23]에 의해 수집 된 브라우저 통계를 살펴 본다. 해당 연도에 사용 된 모든 브라우저 및 해당 버전의 배포판을 제공하는 매년 브라우저 배포가 수집됩니다. WebRTC가 모든 브라우저에 도입 된 시점에 따라 매년 WebRTC 가능 세션의 일부를 결정할 수 있습니다.

이것은 표 4-1에서 데스크탑 및 모바일 / 태블릿 모두에 대해 표시되며, 이는 WebRTC에 대한 브라우저 지원이 급속히 증가하고 있음을 보여줍니다.

이 표는 WebRTC 호출을 설정하는 기능을 보여줍니다.

하지만 불행히도 이러한 사용자가 필요한 오디오 및 비디오 장비를 갖추고 있는지 여부는 고려하지 않았습니다.

4-2 Media Codec

WebRTC는 2 장에서 설명한대로 오디오 및 비디오 스트림을 송수신합니다.

비디오 코덱은 모든 종류의 프레임 속도, 해상도, 색상 수 등으로 웹캠에서 생성 된 원시 비디오 데이터를 가져 와서 크기를 줄이기 위해 압축합니다. 

인코더는 수신측에서 이 원시 데이터와 디코더를 압축 한 다음 압축을 풉니다.

이 과정에서 일부 품질이 손실되지만 필요한 감소된 대역폭에 비해 무게가 나가지 않습니다.

4-1 절에서 설명한 WebRTC의 브라우저 호환성 외에도 다양한 브라우저에서 비디오 코덱을 지원하는 것이 더 심각한 문제입니다.

두 명의 사용자가 전화를 걸면 2-2 절에서 설명한대로 세션 설명 프로토콜을 교환합니다.

이 SDP에서 모든 사용자는 지원하는 오디오 및 비디오 코덱을 지정하며 두 사용자가 하나 이상의 지원되는 오디오 및 비디오 코덱을 공유하는 경우에만 새 비디오 호출을 설정할 수 있습니다.

Q.  클라이언트간에 코덱이 서로 다른 경우 스트림 어떻게 받음?

코덱을 지원해야하는지에 대한 많은 논란이있었습니다. VP8과 H.264는 모두 잠재적 인 후보자입니다.

VP8은 개발자가 라이센스 비용을 지불 할 필요가없는 이점이 있습니다.

H.264는 대부분의 모바일 장치가 H.264의 하드웨어 가속 인코딩 및 디코딩을 지원하기 때문에 선호됩니다.

IETF RTCWEB 그룹은 최근 VP8 및 H.264 지원이 모든 WebRTC 가능 브라우저에 필요하다고 결정했습니다 [24].

현재 Chrome, Firefox 및 Opera는 VP8을 지원하며 H.264 지원을 위해 노력하고 있습니다. Microsoft Edge는 현재 Edge간에 화상 회의를하는 VP8 또는 H.264를 지원하지 않습니다.

중간 미디어 서버 (MCU)가 스트림을 코드 변환하지 않는 한 현재는 불가능한 다른 브라우저가 있습니다.

Microsoft Edge는 앞으로의 오류 수정, 동시 방송 및 확장 가능한 비디오 코딩을 가능하게하기 위해 Skype에서 사용하는 H.264UC를 지원합니다.

Microsoft Edge는 곧 VP8을 지원할 계획이 없지만 크로스 브라우저 화상 채팅을 가능하게하기 위해 H.264 지원 [20]으로 2016 년에 Edge의 새 버전을 출시 할 계획입니다.

또한 VP8의 후속 VP9가 많은 관심을 받고 있습니다. VP9는 VP8이 현재 사용되는 코덱 협상시 VP9보다 선호 되더라도 Chrome, Firefox 및 Opera에서 이미 지원됩니다.

VP9는 더 많은 연산 능력을 필요로하지만 압축 비디오를 강화할 수 있으므로 더 낮은 대역폭이 필요합니다.

VP9는 고품질 비디오 스트림 (예 : 4K)을 압축하는 데 적합하며 TURN 서버 및 SFU 모두의 대역폭 비용을 크게 줄입니다. 반면에 계산 능력이 향상되면 휴대 전화의 배터리 수명이 단축됩니다.

VP9 지원은 앞으로도 Microsoft Edge에 제공 될 예정이며 [26], H.264가 도입 된 이후 가능성이 가장 높습니다.

오디오 코덱은 논쟁의 여지가 적으며 모든 브라우저에서 OPUS 오디오 코덱을 선호합니다. 낮은 비트 전송률과 높은 비트 전송률에 사용할 수 있으며 WebRTC 응용 프로그램에서 고품질 오디오가 필요한 경우 OPUS 만 선택할 수 있습니다.

G.711은 IETF 표준에 따라 모든 브라우저에서 필요합니다.

그러나 낮은 품질 때문에이 코덱은 거의 사용되지 않습니다. WebRTC 가능 브라우저에 대한 현재 지원되는 모든 코덱의 요약은 그림 4-2에 나와 있습니다.

4-4 Mobile Support

모바일 장치는 두 가지 방법으로 WebRTC를 지원할 수 있습니다. 브라우저를 통해 또는 custombuilt 응용 프로그램을 통해.

WebRTC는 모바일 장치 용 브라우저를 통해 동일한 방식으로 작동하지만,

피어싱 연결이 성립되기 전에,

먼저 모바일 장치의 (전면) 카메라 사용 권한이 필요합니다. 안타깝게도 Android는 2013 년 8 월부터 Google 크롬 앱을 통해 브라우저를 통해 WebRTC를 지원합니다.

글을 쓰는 시점에서 iOS에 대한 지원은 아직 알려지지 않았습니다.

앞서 언급했듯이 WebRTC는 모바일 장치의 응용 프로그램에서도 구현할 수 있습니다. 사실 iOS가 현재 이 기술을 지원하는 유일한 방법입니다.

WebRTC는 인터넷 브라우저 용으로 설계되고 구현 되었기 때문에,

모바일 앱이 더 복잡해질 수 있습니다.

두 가지 유형의 앱이 있습니다.

1. Hybrid Mobile Application

타사 소프트웨어는 동일한 코드베이스를 사용하는 다양한 모바일 플랫폼을 지원하는 데 사용됩니다.

하이브리드 애플리케이션의 한 유형은 네이티브 코드를 실행하기위한 후크 (hook)를 지원하는 WebView (즉, 인터넷 브라우저)

예를 들어, 사용자의 카메라와 마이크에 액세스하여 이를 브라우저에 다시 제공 할 수 있습니다.

하이브리드 애플리케이션의 또 다른 형태는 컴파일 된 애플리케이션입니다. JavaScript 또는 C #으로 변환하여 각 플랫폼의 원시 코드로 컴파일합니다.

2. Native Mobile Application

모바일 애플리케이션이 예를 들어, iOS 또는 Android를 기본 코드로 사용하는 경우 기본 앱에 대해 이야기합니다. 

이는 일반적으로 앱에서 더 나은 성능과 사용자 경험을 제공하지만 브라우저에 구현 된 WebRTC 지원이 부족합니다.

다행히 WebRTC 프로젝트 [30]는 사용할 수있는 네이티브 API를 제공합니다.

Related Work 

이 장에서는 WebRTC 기반 화상 회의에 대한 유용한 문헌을 공부합니다. 대부분의 관련 연구는 프로토콜의 단일 측면에 초점을 맞추거나 오래된 WebRTC 버전을 사용합니다.

그들의 성과 분석에서. WebRTC와 그 혼잡 제어 알고리즘은 여전히 ​​빠르게 변화하고 있기 때문에, 최근 연구와 구식 연구는 구별됩니다.

흥미로운 사실은 과거에 만들어진 혼잡 제어 알고리즘을 개선하기위한 대부분의 발언과 제안이 실제로 Google Congestion에서 개선되고 심지어 구현된다는 것입니다

오늘날 사용되는 제어 알고리즘. 이전 연구는 6-1 절에서 논의됩니다. 단일 수행 특성에 초점을 둔 논문은 6-2 절에서 연구된다. 마지막으로, 혼잡 제어 알고리즘에 대한 몇 가지 개선을 제안하는 관련 연구가 6-3 장에서 논의된다.

6-1 Early Studies

다른 논문들은 WebRTC가 2011 년에 소개 된 이래로 WebRTC의 성능을 연구했습니다.

[36]에서는 성숙하지 않은 버전의 WebRTC (2013)에서 포괄적 인 성능 평가를 수행합니다. 실제 환경은 일련의 실험을 통해 시뮬레이션됩니다.

그들은 RRTCC 알고리즘 (GCC의 전신)에는 다음과 같은 제한이 있다고 주장한다.

- 대기 시간이 200ms를 초과하면 대역폭 사용량이 줄어 듭니다.

- TCP 교차 트래픽과 경쟁 할 때 WebRTC는 굶어 죽습니다.

- 늦게 도착한 RTP 플로우와 경쟁 할 때 대역폭은 똑같이 분배되지 않습니다

흥미로운 사실은이 백서의 모든 결함이 수정되었음을 알 수 있습니다. 

데이터 속도는 더 높은 레이턴시에서는 더 이상 떨어지지 않지만 대신 레이턴시 변화에 응답합니다.

또한 TCP와 RTP 간의 경쟁은 새로 도입 된 동적 임계 값 (방정식 5-9), 

경쟁 RTP 흐름이 추가 될 때 대역폭이 균등하게 분배되지 않을 때 "후발"효과는 [32]에서와 같이 해결된다.

챕터의 성능 분석에서 모든 문제가 해결되었는지 확인하기 위해 [36]에 나와있는 테스트가 반복됩니다.

늦게 도착한 RTP 플로우에서는 대역폭이 균등하게 분산되지 않습니다.

7-6 Mobile 

8-5 절에서 WebRTC의 모바일 성능을 분석하고 데스크톱 성능과 비교합니다.

Apple iOS와 Google Android가 총 스마트 폰 시장 점유율의 96 % 이상을 차지하기 때문에 [55] 이러한 모바일 운영 체제에만 초점이 맞춰져 있습니다.

섹션 7-6-1에서 Google Android 설정이 설명 된 후 Apple iOS가 섹션 7-6-2에 나와 있습니다.

7-6-1 Google Android

Android 성능 분석을 위해 Android 5.1.1을 실행하는 Samsung Galaxy S6이 사용됩니다.

4-4에서 논의했듯이 안드로이드의 브라우저는 2013 년 8 월부터 WebRTC를 지원해 왔기 때문에 데스크탑 테스트와 동일한 코드베이스를 사용할 수 있습니다. 비록 디폴트

브라우저가 WebRTC를 지원하는 경우 Google 크롬 앱 (v52)이 데스크톱 기능과 동기화 된 기능을 사용합니다.

Google 크롬이 브라우저로 사용 되더라도,

불행하게도 맞춤 비디오 스트림을 주입 할 수 없으므로 장치의 카메라가 성능 분석에 사용됩니다. 기본적으로,

모바일 브라우저에서 WebRTC 호출 용 전면 카메라 만 사용할 수 있습니다.

다행히도 더 나은 품질의 스트림을 제공하고 다른 곳에서 사용 된 Full HD 테스트 시퀀스와 비교할 수있는 후면 카메라에 액세스 할 수있는 해결 방법이 있습니다.

7-6-2 Apple iOS

Apple iOS의 테스트 설정은 불행히도 더 복잡합니다.

작성 당시 iOS의 브라우저는 아직 WebRTC를 지원하지 않습니다. WebRTC 기능 만 가능합니다.

따라서 네이티브 코드를 통해 WebRTC 비디오 채팅을 수행하려면 응용 프로그램을 만들어야합니다. 다행히도 Cordova2

기존 HTML / JavaScript 코드베이스와 함께 사용할 수 있습니다.

WebRTC 기능성 (즉, 시그널링, SDP 교환

등)에 의해 처리됩니다.

Cordova는 하이브리드 iOS 응용 프로그램에서 기존 코드베이스를 래핑하여 JavaScript가 기본 (Objective C / Swift) 기능을 호출하도록합니다.

다행히도 Cordova 플러그인 codeova-plugin-iosrtc [56]가 활발하게 유지 관리되고 있습니다.

이 플러그인은 W3C 표준에 따라 전체 WebRTC JavaScript API를 제공하며 JavaScript가 iOS 카메라에 액세스하고 RTCPeerConnection을 설정하며 네이티브 VideoViews에 로컬 및 원격 비디오 스트림을 모두 표시 할 수 있습니다.

구현 된 응용 프로그램은 실험을 수행하는 데 사용되는 iOS 9.3.1이 설치된 Apple iPhone 6에 설치됩니다. 아이폰 6은 삼성과 비슷한 성능을 가지고있다.

Galaxy S6 [57] 따라서 공정한 비교를 제공해야합니다.

Android와 마찬가지로 피어 연결에 맞춤 비디오를 제공 할 수 없으므로 기본 getUserMedia () 코드가 수정되어 후면 카메라가 사용됩니다.

Performance Analysis

7 장에서 설명한 테스트 설정을 기반으로 특정 WebRTC 화상 회의의 성능에 어떤 영향이 미치는지 확인하기 위해 몇 가지 테스트가 수행됩니다. 

8-1 절에서 추가적인 대기 시간의 영향,

WebRTC 기반 비디오 채팅 중 패킷 손실 또는 제한된 대역폭이 분석됩니다.

8-2 절에서, 네트워크 적응 능력은 WebRTC 통화 중에 이러한 다른 네트워크 매개 변수를 변경합니다.

8-3 절은 최대 4 명까지 다양한 다자 솔루션에 대한 WebRTC의 성능을 설명합니다.

8-4 절에서는 경쟁 교차 트래픽에 대한 공정성이 테스트됩니다.

휴대 기기의 성능은 섹션 8-5에서 분석 한 다음 섹션 8-6에서 크로스 브라우저 비교를 수행합니다.

8-7 절에서 서로 다른 비디오 코덱을 비교하고 8-8 절에서 실제 인터넷을 통한 WebRTC 호출을 분석합니다.

8-1 Network characteristics

5 장에서 볼 수 있듯이 WebRTC의 많은 성능은 두 참여자 간의 연결 특성에 따라 달라집니다. 수신 측과 송신 측은 각각

제한된 대역폭의 영향을받는 동안 지연 시간 변화와 패킷 손실에 기반한 데이터 전송률 통화에 영향을줍니다. 

이 섹션에서 참조 포인트는 다음과 같은 제한되지 않은 링크에 만들어집니다.

8-1-1 절, 대기 시간 변경 (8-1-2 절), 패킷 손실 (8-1-3 절) 및 사용 가능한 대역폭 (8-1-4 절)은 WebRTC의 성능에 영향을줍니다. 

사람 WebRTC 화상 채팅 세션.

8-1-1 Unconstrained link

참고로 네트워크에 대한 제한없이 WebRTC의 성능을 먼저 테스트합니다.

이것은 후속 테스트의 참고 자료로 사용할 수 있습니다.

5 분 제약없는 테스트의 평균 결과는 표 8-1에 나와 있습니다.

위의 표에서 WebRTC는 현재 브라우저 1에서 설정된대로 2.5Mbps로 전송하는 것으로 제한되어 있음을 알 수 있습니다. 또한 대기 시간 (약 1ms) 및 패킷 손실이 거의없고,

WebRTC는 7 장에서 설명한 테스트 베드를 사용하여 원래 해상도 (1920 x 1080) 및 프레임 속도 (50 FPS)로 비디오를 완벽하게 전송할 수 있습니다.

위의 결과는 다음 섹션에서 다양한 네트워크 효과를 비교하는 데 사용됩니다.

8-1-2 Latency

첫째, 5 분 WebRTC 호출에 추가 대기 시간을 적용하여 통신 지연의 영향을 테스트합니다.

세 가지 대기 시간이 업 링크 및 다운 링크 방향 모두에서 테스트됩니다.

100ms, 250ms 및 500ms로 설정하여 각 왕복 시간을이 값의 두 배로 만듭니다. 결과는 표 8-2에 나와 있으며 시간에 따른 결과 데이터 속도는 그림 8-1에 나와 있습니다.

Google 혼잡 제어 알고리즘은 대기 시간 변동에만 반응하기 때문에 예상 지연 시간은 데이터 속도 또는 스트림 품질에 영향을주지 않지만 대화에 지정된 지연을 추가합니다. ITU-T 권고안 G.114 [59]는 양방향 전송 지연이 150ms 미만으로 유지되어야하며, 400ms를 초과하는 지연은 용인되지 않는 것으로 규정한다. 지연을 추가 할 때 유일한 다른 효과는 호출을 설정하고 양 끝점간에 데이터가 흐르게하는 데 더 오래 걸리는 것입니다 (그림 8-1). 데이터가 흐르면 추가되는 지연에 관계없이 최대 데이터 속도에 도달하는 데 약 10 초가 걸립니다. 이 시동 지연은 GCC 방정식의 데이터 속도 증가 요인에서 예상보다 적으며,

WebRTC는 연결이 설정되면 최대한 빨리 가능한 최대 데이터 속도를 얻기 위해 램프 업 기능 2를 사용하기 때문에.

8-7 Video codecs 

기본적으로 Chrome은 WebRTC 화상 통화에 VP8 비디오 코덱을 사용합니다. Google 크롬 v48 이후로 후속 VP9에 대한 지원이 추가되었습니다. VP9는 4-2 절에서 설명한 것처럼보다 효율적인 압축 효율로 인해 낮은 비트 전송률에서 VP8과 동일한 객관적 품질을 제공합니다 [62]. 그러나 이것은 여분의 비용으로 발생합니다.

CPU 전원. 따라서 VP9는 대역폭이 제한되어 있거나 (예 : 셀룰러 및 혼잡 한 네트워크에서) 또는 낮은 비트 전송률에서 동일한 품질을 원할 때 유용 할 수 있습니다. Chrome v50에는 H.264 비디오 코덱 지원 기능이 추가되어 많은 기기에서 하드웨어 가속 디코딩이 가능합니다. 이러한 새로 지원되는 코덱은 기본적으로 사용되지 않지만,

WebRTC는 7-2-2에서 설명한대로 생성 된 SDP (Session Description Protocol)를 변경하여 강제로 사용할 수 있습니다. 이 섹션에서는 VP8, VP9 및 H.264 비디오 코덱을 비교합니다.

새로 추가 된이 코덱은 아직 개발 단계에 있기 때문에 인코딩 및 디코딩 중에 CPU 제한을 방지하기 위해 720p 변형 미디어 스트림이 사용됩니다. 먼저 그림 8-15와 같이 네트워크 제한없이 5 분간의 테스트가 수행됩니다.

이는 VP8이 VP8과 비슷한 동작을하는 반면 H.264는 일정한 데이터 속도를 유지할 수 없음을 나타냅니다.

다른 모든 통화 특성은 비슷합니다. 원래의 해상도와 프레임 속도는 빠르게 도달하고 RTT는 낮으며 패킷 손실은 관찰되지 않습니다. 더 흥미로운 점은 다양한 비디오 코덱이 표 8-7에 설명 된 7 분 테스트에서 어떻게 작동하는지 확인하는 것입니다.

결과는 그림 8-16과 표 8-11에 나와 있습니다.

데이터 속도에 따라 H.264는 제한된 대역폭의 영향을 많이받으며 VP8 및 VP9와 비교할 때 대기 시간이 추가되었음을 즉시 알 수 있습니다. H.264는 또한 데이터 전송 속도가 다릅니다. VP8과 VP9가 프레임 속도와 해상도 사이에서 균형을 이루는 경우 H.264는 일정한 최대 해상도를 유지하면서 프레임 속도를 낮 춥니 다.

이로 인해 프레임 속도가 1 분 2 초 정도에 1FPS로 떨어집니다. VP9는 VP8보다 효율적인 압축 기능으로 인해 혼잡이 발생할 때 VP8보다 성능이 뛰어납니다.

이는 분 1에서 3까지의 더 높은 해상도에서 볼 수 있습니다. 분 3 또는 분 5에서 혼잡이 제거되면 VP8은 VP8이 수행하는 동안 원래 해상도 (1280x720)까지 스케일 업하지 않습니다.