webrtc1

틀린것 많음… 보완할 예정

알아두어야할 용어설명

  • Candidate
    Peer to Peer 통신을 위해 접근할수 있는 경로들의 후보.

  • ICE(Interactive Connectivity Establishment)
    브라우저가 peer 연결 할 수 있도록 지원하는 프레임워크. ICE는 이러한 작업을 수행하기 위해 STUN과 TURN 서버 둘다 혹은 하나의 서버를 사용.

  • STUN (Session Traversal Utilities for NAT)
    클라이언트는 인터넷을 통해 클라이언트의 공개주소와 라우터의 NAT 뒤에 있는 클라이언트가 접근가능한지에 대한 답변을 위한 요청을 STUN서버에 보냅니다. 즉 자신의 공인 IP를 STUN에 요청하고 이후 통신시도함.
    STUN의 경우에는 구글의 오픈서버를 사용하면 됨

  • TURN (Traversal Using Relays around NAT )
    STUN을 통했으나 Peer을 서로 못찾았을 때 이를 활용한다. 이 방식은 TURN 서버를 통해 서로 통신하므로 (Proxy를 생각하면 좋다)비용이 많이든다.
    외부에 있는 사람들과 화상 통화를 하려면 TURN 서버가 필수적인데 미디어와 영상이 해당 서버를 통해 거쳐간다(proxy를 생각하자).
    TURN 서버와 연결을 한 후 모든 peer들에게 저 서버에 모든 패킷을 보내고 다시 나에게 전달해달라고 해야 합니다. 이것은 명백히 오버헤드가 발생하므로 이 방법은 다른 대안이 없을 경우만 사용하게 됨.
    서버 부하가 많으므로 무료로 제공하는곳을 찾기힘듦

  • SDP (Session Description Protocol )
    해상도나 형식, 코덱, 암호화등의 멀티미디어 컨텐츠의 연결을 설명하기 위한 표준입니다.

  • Signaling
    WebRTC는 P2P 통신이지만 이를 중계하는 서버가 필요한데 이를 시그널 서버라 한다. 중계라 하면 연결을 위한 데이터(SDP, Candidtate) 요청 등…WebRTC에서 제공하는것은 아님

https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API/Protocols 그림넣기

채널생성

Channel API를 통해 채널을 생성하는 방식은 다음과 같습니다
클라이언트 A가 하나의 유니크 ID를 생성합니다.
클라이언트 A는 자신의 ID를 App Engine 앱에 넘겨주면서 채널 토큰을 요청합니다.
App Engine 앱은 Channel API로 부터 채널과 클라이언트 ID에 해당하는 토큰을 요청합니다.
앱은 토큰을 클라이언트 A에게 전달합니다.
클라이언트 A는 소켓을 열고 서버에 설정된 채널로부터 메세지를 기다립니다.

메세지 전송

클라이언트 B는 변경사항과 함께 App Engine 앱으로 POST 요청을 보냅니다.
App Engine 앱은 요청을 channel을 통해 전달합니다.
채널은 메세지를 클라이언트 A에게 전달합니다.
클라이언트 A의 onmessage 콜백함수가 호출됩니다.

WebRTC의 제공 API

1.MediaStream: 사용자의 카메라와 마이크 같은 곳의 데이터 스트림에 접근합니다. 이를 PeerConnection에 전달하여 미디어를 전송함
2.RTCPeerConnection: 암호화 및 대역폭 관리를 하는 기능을 가지고 있고, 오디오 또는 비디오 교환을 합니다.
3.RTCDataChannel: 데이터 통신을 지원하는 채널.

1.MediaStream

https://simpl.info/getusermedia/ 에 들어가서 소스코드를 분석해보자.

getUserMedia() 함수는 아래와 같이 세개의 요소가 필요

  • constraints
  • 에러핸들링 함수
  • 성공했을 때 함수
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
var constraints = {
video: true
};

function handleSuccess(stream) {
window.stream = stream; // only to make stream available to console
video.srcObject = stream;
}

function handleError(error) {
console.log('getUserMedia error: ', error);
}

navigator.mediaDevices.getUserMedia(constraints).
then(handleSuccess).catch(handleError);

2.RTCPeerConnection

먼저 Signaling 이란: session control, network and media information

RTCPeerConnection을 위해 Signaling으로 알려진 일련의 과정이 필요하다.

Signaling 메세지의 요소들은 다음과 같다.

  • Session control messages: 통신의 초기화, 종료 그리고 에러 리포트 정보
  • Network configuration: 내 컴퓨터의 IP 주소와 Port 정보
  • Media capabilities: 내 브라우저와 상대브라우저가 사용 가능한 코덱들과 해상도 정보
    이 시그널링 프로세스는 클라이언트에서 메세지를 송신하는 방법을 필요로 합니다. 그 메커니즘은 WebRTC API에 의해 구현되지 않습니다
    시그널링을 위해 오가는 데이터는 SDP(Session Description Protocol) 형태이다.
    시그널링 간 오가는 데이터는 ice 서버에서 얻어온다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
var signalingChannel = createSignalingChannel();
var pc;
var configuration = ...;

// run start(true) to initiate a call
function start(isCaller) {
pc = new RTCPeerConnection(configuration);

// send any ice candidates to the other peer
pc.onicecandidate = function (evt) {
signalingChannel.send(JSON.stringify({ "candidate": evt.candidate }));
};

// once remote stream arrives, show it in the remote video element
pc.onaddstream = function (evt) {
remoteView.src = URL.createObjectURL(evt.stream);
};

// get the local stream, show it in the local video element and send it
navigator.getUserMedia({ "audio": true, "video": true }, function (stream) {
selfView.src = URL.createObjectURL(stream);
pc.addStream(stream);

if (isCaller)
pc.createOffer(gotDescription);
else
pc.createAnswer(pc.remoteDescription, gotDescription);

function gotDescription(desc) {
pc.setLocalDescription(desc);
signalingChannel.send(JSON.stringify({ "sdp": desc }));
}
});
}

signalingChannel.onmessage = function (evt) {
if (!pc)
start(false);

var signal = JSON.parse(evt.data);
if (signal.sdp)
pc.setRemoteDescription(new RTCSessionDescription(signal.sdp));
else
pc.addIceCandidate(new RTCIceCandidate(signal.candidate));
};

3.RTCDataChannel

오디오와 비디오처럼, WebRTC는 실시간으로 다른 형태의 데이터 통신도 지원

헷갈리는 부분…

시그널링을 위한 서버는 필요함.
시그널링서버와 STUN, TURN서버는 다른개념. 즉 따로존재해야함
Peer-to-Peer 통신을 위해서는 브라우저 간 통신 가능
그룹 커뮤니케이션을 위해서는 미디어 서버가 필요함.(ex Janus Gateway / kurento- signaling 미지원)

릴레이서버??? p2p 커뮤니케이션 통신이 실패하면 turn 서버를 활용한 통신한다. == TURN 서버

미디어서버(MCU/SFU) :

#MCU(Multipoint Control Unit)란?
-다대다 통신에서 미디어 서버는 여러 미디어 스트림을 하나의 스트림으로 만든 후 클라이언트에게 제공합니다.
-서버의 CPU 부하가 SFU에 비해 높은 편이지만, 사용자는 SFU에 비해 더 적은량의 데이터로 미디어 스트림을 받을 수 있습니다.

#SFU(Selective Forwarding Unit)란?
-다대다 통신에서 미디어 서버는 여러 미디어 스트림을 하나로 만들기 위한 디코딩, 인코딩 작업 없이 클라이언트에게 제공합니다.
-서버의 CPU부하가 MCU에 비해 낮은 편이지만, 사용자는 MCU에 비해 더 많은량의 데이터를 수신해야 합니다.

일대일/일대 다일때 TURN 통신
브라우저가 시그널링 서버에 접근하면 시그널링 서버는 TURN의 채널을 열게된다.
일대 다일땐 브라우저가 TURN채널에 전송하고 TURN은 다시 미디어서버로 전송한다.

브라우저-TURN을 통해 미디어 서버 주소 알아옴-미디어서버-TURN을 통해 원격 주소 알아옴-브라우저
TURN 안쓸때 브라우저-STUN을 통해 미디어서버 주소를 알아옴-미디어서버-STUN을 통해 원격주소 알아오고 -브라우저???

시그널 서버가 미디어서버와 통신하는 턴 채널을 생성.

STUN은 일대일 용도(완벽하지않지만 이렇게 생각이 편함)
TURN은 일대 다

https://cryingnavi.github.io/WebRTC-Basic/
https://www.dinobot.info/95

https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API/Protocols

https://www.html5rocks.com/ko/tutorials/webrtc/basics/#toc-mediastream
https://www.html5rocks.com/ko/tutorials/webrtc/infrastructure/

https://m.blog.naver.com/PostView.nhn?blogId=djjproject&logNo=220896510901&proxyReferer=http:%2F%2F59.29.251.41%2Ftm%2F%3Fa%3DCR%26b%3DWIN%26c%3D300023095277%26d%3D32%26e%3D5206%26f%3DbS5ibG9nLm5hdmVyLmNvbS9kampwcm9qZWN0LzIyMDg5NjUxMDkwMQ%3D%3D%26g%3D1591597231415%26h%3D1591597230428%26y%3D0%26z%3D0%26x%3D1%26w%3D2020-02-18%26in%3D5206_1520_00016662%26id%3D20200608

Share