WebRTC: Difference between revisions

From 탱이의 잡동사니
Jump to navigation Jump to search
(Created page with "== Overview == WebRTC 내용 정리 == Basic == WebRTC(Web Real-Time Communication)는 웹 브라우저 간에 플러그인의 도움 없이 서로 통신할 수 있도록...")
 
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 4: Line 4:
== Basic ==
== Basic ==
WebRTC(Web Real-Time Communication)는 웹 브라우저 간에 플러그인의 도움 없이 서로 통신할 수 있도록 설계된 API 이다. W3C에서 제시된 초안이며, 음성 통화, 영상 통화, P2P 파일 공유 등으로 활용될 수 있다.
WebRTC(Web Real-Time Communication)는 웹 브라우저 간에 플러그인의 도움 없이 서로 통신할 수 있도록 설계된 API 이다. W3C에서 제시된 초안이며, 음성 통화, 영상 통화, P2P 파일 공유 등으로 활용될 수 있다.
=== Peer-to-peer ===
The problems with peer-to-peer communication for WebRTC start with multiparty calls. In a multiparty call scenario, every participant must send his or her media content to all other participants. If assume that there are N participants in the call, the same media stream must be sent N-1 times over an uplink to the N-1 participants. This requires a significant amount of uplink bandwidth from participants.
Furthermore, there is also a significant computational cost for each client device, as it must encode the same stream multiple times. In practice, direct peer-to-peer communication works well if the number of call participants is low.
=== MCU(Multipoint Conferenceing Unit) ===
Multipoint Conferencing Units(MCUs) have been used successfully for many years with legacy conferencing systems. The MCU architecture assumes that each conference participant sends his or her stream to the MCU. The MCU decodes each received stream, rescales it, composes a new stream from all received stream, encodes it, and sends a single to all other participants.
The MCU approach requires very little intelligence in device endpoints, as the majority of the logic is located in the MCU itself. The unit can generate ouput streams with different quality for different participants depending on their specific downlink counditions. This makes MCUs a solid solution for low capacity networks. Since the MCU approach has been used widely in the industry for many years, it is a very good solution if interoperability with legacy system is required.
The main disadvantage of MCU is its cost, as it decodes and re-encodes streams to compose the final stream, hence requires significant computing power by the MCU. A secondary disadvantage is in delay, the recomposing the picture can be hampered by packet loss on one of the links, as it must wait for the complete frame to encode.
=== SFU(Selective Forwarding Unit) ===
Selective Forwarding Units(SFUs) are the most popular modern approach. In the SFU architecture, every participant sends his or her media stream to a centralized server(SFU server) and receives streams from all other participants via the same central server. The architecture allow
== See also ==
* https://wiki.asterisk.org/wiki/display/AST/WebRTC+tutorial+using+SIPML5 - WebRTC tutorial using SIPML5
* https://www.callstats.io/blog/webrtc-architectures-explained-in-5-minutes-or-less - WebRTC Architectures Explianed in 5 minutes or less


[[category:telephony]]
[[category:telephony]]

Latest revision as of 12:53, 27 July 2020

Overview

WebRTC 내용 정리

Basic

WebRTC(Web Real-Time Communication)는 웹 브라우저 간에 플러그인의 도움 없이 서로 통신할 수 있도록 설계된 API 이다. W3C에서 제시된 초안이며, 음성 통화, 영상 통화, P2P 파일 공유 등으로 활용될 수 있다.

Peer-to-peer

The problems with peer-to-peer communication for WebRTC start with multiparty calls. In a multiparty call scenario, every participant must send his or her media content to all other participants. If assume that there are N participants in the call, the same media stream must be sent N-1 times over an uplink to the N-1 participants. This requires a significant amount of uplink bandwidth from participants.

Furthermore, there is also a significant computational cost for each client device, as it must encode the same stream multiple times. In practice, direct peer-to-peer communication works well if the number of call participants is low.

MCU(Multipoint Conferenceing Unit)

Multipoint Conferencing Units(MCUs) have been used successfully for many years with legacy conferencing systems. The MCU architecture assumes that each conference participant sends his or her stream to the MCU. The MCU decodes each received stream, rescales it, composes a new stream from all received stream, encodes it, and sends a single to all other participants.

The MCU approach requires very little intelligence in device endpoints, as the majority of the logic is located in the MCU itself. The unit can generate ouput streams with different quality for different participants depending on their specific downlink counditions. This makes MCUs a solid solution for low capacity networks. Since the MCU approach has been used widely in the industry for many years, it is a very good solution if interoperability with legacy system is required.

The main disadvantage of MCU is its cost, as it decodes and re-encodes streams to compose the final stream, hence requires significant computing power by the MCU. A secondary disadvantage is in delay, the recomposing the picture can be hampered by packet loss on one of the links, as it must wait for the complete frame to encode.

SFU(Selective Forwarding Unit)

Selective Forwarding Units(SFUs) are the most popular modern approach. In the SFU architecture, every participant sends his or her media stream to a centralized server(SFU server) and receives streams from all other participants via the same central server. The architecture allow

See also