안드로이드 WebRtc 시작하기 -2

 이번에는 PeerConnection의 작동 방식과 Android에서의 구현 방법에 대해 자세히 살펴 보겠습니다.

첫째, WebRTC는 피어 - 투 - 피어 연결 (또는 단순히 P2P)을 기반으로합니다. 그렇다면 P2P는 무엇일까요?

위키 피 디아에 P2P에 대해 설명되어 있습니다.

피어 - 투 - 피어 (P2P) 컴퓨팅 또는 네트워킹은 피어간에 작업 또는 작업 부하를 분할하는 분산 응용 프로그램 아키텍처입니다. 피어는 동등하게 권한이 부여되며 응용 프로그램에서 동일한 권한을 가진 참가자입니다. 이들은 피어 투 피어 노드 네트워크를 형성한다고합니다.

따라서 WebRTC를 사용하면 외부 서버 컴퓨터없이 오디오 / 비디오 스트림을 다른 피어와 직접 공유 할 수 있습니다. 인프라에서 대량의 오디오 / 비디오 데이터로 인해 과부하가 걸리지 않으므로 기업에 큰 이점입니다.

• 피어는 네트워크에 연결된 장치이다.
• 피어간에 데이터를 공유하는 것은 피어가 연결된 네트워크에서 허용하는 경우에만 가능합니다. (STUN/TURN에 대해서 살펴보겠습니다.)
• WebRTC에서는 "Rooms"이라는 개념을 사용하여 서로 연결된 피어를 식별합니다.
• 많은 peer가 하나의 룸에 연결되어 동일한 룸의 다른 peer와 자원을 공유 할 수 있습니다.
• Signaling 은 peer정보를 룸에 연결되어있는 peer들에게 알려주기에 필요합니다.

Signaling

WebRTC가 P2P 통신을 처리하더라도 peer가 통신 할 수 있도록 일부 신호 메커니즘을 지정해야합니다.

WebRTC에는 Signaling이 포함되어 있지 않으므로 요구에 맞는 메커니즘을 자유롭게 선택할 수 있습니다.

WebRTC는 보안 네트워크에서만 작동합니다. 데이터 전송이 보안 채널에서 수행된다는 보장을 제공합니다. 신호 메시지에 보안 채널을 사용하는 것은 개발자의 몫입니다.

Sdp

SDP란 연결하고자 하는 peer 서로간의 미디어와 네트워크에 관한 정보를 이해하기 위해 사용됩니다.

WebRTC는 Offer 및 Answer의 두 가지 주요 구성 요소가 있습니다. 이 두가지 요청에는 장치에서 사용 할 수 있는 오디오/비디오 인코딩 형식, 네트워크 세부 정보 등을 제공합니다.

예를 들어 설명하겠습니다.

• A가 offer를 만들고 "room"룸에 offer를 정송합니다.
• A는 offer를 기억하기위해 자신의 저장소에 안전하게 저장합니다.
• B는 offer를 받고 A의 개인정보를 안전하게 보관합니다.
• B는 A의 offer에 대해 응답합니다.
• A는 B의 대답을 받아 안전하게 저장합니다.
• A와B는  오디오 / 비디오 및 기타 중요한 세부 사항을 지정하는 IceCandidates를 공유합니다.
• 이제 A와 B는 그들에 대한 메타 정보와 서로에 대한 정보를 가지고 있습니다. A는 이제 B와 직접적인 연결 고리를 만들 수 있습니다.

A가 offer를 생성할때 A는 initiator라고 불립니다. A가 만들고 저장한 offer는 A의 local description 입니다.

B가 offer를 받았을때 B는 offer를 remote description 로 저장하고 B는 자신의 local description으로 대답합니다.

SDP로 제안 및 답변을 전송하는 것은 모든 매체에서 발생할 수 있습니다. WebSockets, Google 클라우드 메시징 시스템, XMPP, SIP, RTCDataChannel 등이 될 수 있습니다.

비록 P2P 연결에는 서버 연결이 필요하지 않지만 WebRTC의 신호부분에는 서버가 세션,룸 및 peer를 관리해야 합니다.

Signaling 메시지는 대부분의 오디오/비디오 데이터보다 작습니다.

하지만 Signaling 메시지가 작을지라도 많은 사용자를 지원하기 위해서는 signaling 시스템을 확장 하는것에 대해서 생각해야합니다.

STUN and TURN

발신자가 수신자에게 신호를 보내는 방법을 알았으므로 전화를 걸 수 있습니다. 하지만 NAT 게이트웨이와 방화벽이 있어 문제가 됩니다.

WebRTC는 이러한 NAT 게이트웨이와 방화벽을 해결할 수 있습니다. 그것은 바로 STUN과 TURN입니다.

간단하게 말해서,

• P2P 연결은 피어가 다른 피어의 공용 IP : 포트 조합을 알고있는 경우에만 발생할 수 있습니다. 이것은 NAT로 보호되는 네트워크에서는 불가능합니다.
• STUN은 들어오는 요청의 공용 IP : 포트를 찾아서 그 주소를 응답으로 보내는 공용 서버입니다. 피어는 STUN을 사용하여 공개 IP : 포트를 알 수 있습니다 (NAT는 피어에게 직접 정보를 제공하지 않음)
• STUN은 대역폭을 많이 사용하지 않으며 우리가 사용할 수있는 많은 공개 STUN 서버가 있습니다.
• NAT가 UDP / TCP 오디오 / 비디오 스트림을 차단하지 않는 우리는 우리가 얻은 STUN 응답으로 NAT를 통해 WebRTC를 통신 할 수 있습니다.
• TURN 서버는 피어의 프록시 역할을하는 릴레이입니다. TURN 서버는 공용 IP : 포트를 가지므로 피어가 방화벽 뒤에서도 직접 통신 할 수 있습니다.
• 각 피어는 자신의 미디어 데이터를 다른 피어로 중계하는 TURN 서버로 전송합니다.
• 적은 양의 데이터를 처리하는 STUN과 달리 TURN은 대형 미디어 스트림을 처리하므로 프로덕션 응용 프로그램을 위해 확장 할 수 있어야합니다.
• TURN 서버는 비용이 많이 들고 무료로 사용할 수 없습니다.

TURN은 신호 데이터가 아닌 피어간에 오디오 / 비디오 / 데이터 스트리밍을 릴레이하는 데 사용됩니다.

TURN는 한 사람에게서 다른 사람에게 메시지를 전하는 메신저와 같습니다. 미디어 스트림에는 아무 것도하지 않습니다.

Media Servers

 WebRTC는 두 peer가 서로 통신 할 수 있도록 완벽하게 작동합니다. peer 그룹이 의사 소통하기를 원할 때 어떤 일이 벌어 질지 상상해봅시다.

아래에는 모든 피어가 모든 다른 피어에 연결된 완전한 메쉬 네트워크입니다.

• 이 접근 방식은 연결에서 더 적은 수의 피어에 적합합니다. 그러나 과도한 중복 및 높은 대역폭 요구 사항으로 인해이 수치가 통제 할 수 없을 정도로 커질 수 있습니다.
• 이 방법은 스마트 폰과 같이 대역폭이 낮은 장치에는 적합하지 않습니다.
• MCU (Multipoint Control Unit)가 출시되었습니다. 이들은 풀 메시 토폴로지 대신 스타 토폴로지를 만드는 데 도움이되는 특정 하드웨어 / 소프트웨어 기술입니다.
• 미디어 서버는 모든 피어의 피어 역할을합니다. 네트워크의 모든 피어를 추적하고 다른 피어의 데이터를 전송합니다.
• 스타 토폴로지의 각 피어는 MCU에만 연결되며 네트워크의 다른 피어에 대한 네트워크 연결은 없습니다.