WebRTC) 프로토콜을 사용한 영상통화의 기본적인 원리

예전에 스터디에서 발표자료로 만들었던 피피티를 발견해서 블로그에 공유 해보려 한다.

발표 자료로 사용하던 내용을 그대로 가져와 서체가 사용자 친화적이 아닙니다.

 

 

WebRTC는 피어 간 고품질 오디오 / 비디오 / 데이터 전송을 제공하는 데 사용할 수있는 피어 투 피어 연결 프레임 워크입니다.

모바일 플랫폼의 경우 피어 연결 기본 라이브러리를 포함시켜야 작동합니다.

 

1. PeerConnection의 작동방식

2. STUN / TURN / ICE 및 기타 정보

 

P2P?

Peer to Peer

-> 간단히 말해 WebRTC를 사용하면 외부 서버 컴퓨터없이 오디오 / 비디오 스트림을 다른 피어와 직접 공유 할 수 있습니다.

peer는 네트워크에 연결된 장치 -> 피어간 데이터 공유는 연결된 네트워크에서 허용된 경우에만 가능

 

Signaling?

WebRTC가 P2P 통신을 처리하지만 피어가 통신 할 수 있도록 어떤 신호 메커니즘을 지정해야합니다.

WebRTC는 신호가 포함되어 있지 않기 때문에, 개발자는 필요에 따라 자신 만의 방식을 자유롭게 선택할 수 있습니다.

WebRTC가  통신은 offer와 response가 있다.

위 두 메타데이터는 SDP방식으로 소통함 -> SDP의 제안과 응답은 웹소켓, 구글 클라우드 메시징 등 어느 매체에서도 발생함 -> 시그널서버를 개발자 마음대로 선택할 수 있다는 얘기

신호 서버가 필요하지만 대량의 오디오/비디오 데이터를 전송하는게 아니라 그냥 룸참가자 관리임

 

STUN and TURN?

이제 발신자가 수신자에게 신호를 보내는법을 알았기때문에 call을 할 수 있습니다.

하지만 우리는 NAT과 방화벽이 있어 통신을 할 수 없습니다.

-> STUN과 TURN 필요한 이유임

P2P 통신은 본래 한 피어가 다른 피어의 공용IP:port 조합을 알고 있어야 가능합니다.

NAT으로 보호된 네트워크에서는 불가능함

ICE프레임워크 사용해서 네트워크의 복잡성을 해결할 수 있음

ICE서버는 피어들을 연결시키기 위해 최적의 경로를 찾으려하고, 가장 효율적인 방법을 찾으려함

 

 

 

ICE는 STUN 서버를 이용하여 외부 주소를 획득하고 그것이 실패한다면 TURN 중계 서버를 통해 트래픽을 라우팅합니다.

STUN은 공용서버이며 요청이 들어오는 공용 IP:PORT를 찾아 해당 주소를 응답으로 전송해주는일을 합니다.

//STUN은 대역폭을 많이 사용하지 않고 많은 공용STUN서버가 있음

->NAT가 UDP / TCP 오디오 / 비디오 스트림을 차단하지 않고 WebRTC는 STUN 응답을 통해 NAT를 통해 통신 할 수 있습니다.

다시말해

STUN 서버는 외부 네트워크 주소를 얻는데 사용됩니다.

TURN 서버들은 직접(P2P) 연결이 실패할 경우 트래픽을 중계하는데 사용됩니다.

 

 

 

NAT들은 사설 로컬 네트워크에서 디바이스에 IP 주소를 제공하지만 이 주소는 외부에서 사용될 수 없습니다. 공용 주소가 없이는 WebRTC 피어(Peer)들은 통신할 수 있는 방법이 없습니다.

STUN은 대역폭을 많이 사용하지 않으며 사용할 수있는 많은 공용 STUN 서버가 있습니다.

NAT가 UDP / TCP 오디오 / 비디오 스트림을 차단하지 않는 환경에서 WebRTC는 STUN 응답을 통해 NAT를 통해 통신 할 수 있습니다.

그러나 NAT가 너무 제한적인 경우에는 TURN (NAT 주변의 릴레이를 사용하는 탐색)이 사용됩니다.

적은 양의 데이터를 처리하는 STUN과 달리 TURN은 큰 미디어 스트림을 처리합니다.

 

 

Media Servers

그룹통화는 어떻게 처리할까?

옆 그림은 모든 피어 각각이 연결되어있는것

//적은 수의 연결이면 충분히 가능, 높은대역폭으로 제어 범위를 넘어서면 실패하게 됨

-> 따라서 스마트폰같은 저 대역폭 장치에는 걸맞지 않음

-> 3인이상 통신을위해 MCU(Multipoint Control Unit)라는게 필요하다 함

MCU는 피어들 모두에 대해 피어로 작용

즉, 각각의 피어는 MCU에만 연결하면 나머지 모두와 연결된것과 같은효과

 

 

 

 

1. 처음에 이 앱은 피어 연결과 오퍼SDP를 만듭니다.

2. 오퍼는 local description에 저장되고 신호 매커니즘을통해 수신자에게 전달된다.//시그널서버(주로 웹소켓)을 통해

3. 상대가 수신을 허용하면 받아온 오퍼를 remote description에 저장하고, 응답 SDP를 만든다.

//응답 SDP는 발신자의 SDP와 비슷함

4. 응답 SDP를 발신인은  remote description에 저장한다.

//각자 자기꺼를 local, 상대꺼는 remote에 저장

5. 발신자, 수신자는 ice candidate를 전송한다.

이러한 후보를 수신하면 피어는 이러한 후보들을 PeerConnection 인스턴스에 추가합니다.

 

webRTC + Android

 

시작에 앞서 app수준 gradle에 webRTC 라이브러리 추가해줌

최신버전은 지금과 다를 수 있음