[WebRTC] WebRTC 동작 과정 - Signaling, WebRTC 아키텍처

개요 및 복습

지난 시간 일반적인 웹소켓과 WebRTC 통신을 비교해보았다. 요약하자면 다음과 같다.

• WebRTC란 멀티미디어 및 스트리밍에 특화된 P2P 통신 기술이다.
• 웹소켓은 브라우저 간 통신을 도와주는 중개 서버가 존재하지만, WebRTC는 브라우저끼리 통신 가능하다.
• 대신 WebRTC는 초기 연결 수립을 위한 “시그널링 서버”가 필요하다.

 

 

WebSocket

WebRTC

이번 시간에는 시그널링 과정에 대해 알아보고 다양한 서버 구축 방식에 대해 알아보고자 한다. 기본적인 용어는 🔗[WebRTC] 개념 및 용어 정리 에 정리되어있으므로 생략하겠다.

 

---

Signaling

 

Transport 메커니즘?

WebRTC에서는 별도의 transport 메커니즘을 제시하진 않는다. 참고로 Transport 메커니즘이란 시그널링 정보를 전달하는 방법을 말한다. 즉 웹소켓이든 XMLHttpRequest이든 시그널링 데이터만 주고받을 수 있다면 어떤 방식을 선택하든 상관하지 않는다. 또한 시그널링 서버는 이 시그널링 데이터 내용을 알지 못해도 상관없다. 그저 두 피어가 이 정보를 공유할 수 있도록 전달하는 역할만 수행하면 된다.

 

 

Signaling 정보

시그널링 과정에서 크게 세 유형의 정보를 교환하게 된다.

• 통신을 열거나 닫고, 에러를 처리하기 위한 제어 메시지
• IP 주소, 포트 등 연결을 설정할 때 필요한 정보 → ICE
• 미디어 capability: 피어 간 합의된 미디어 유형, 코덱 등 → SDP

Signaling 프로세스

두 피어는 먼저 서로의 SDP를 교환하여 capability를 협상한다. 이를 통해 어떤 미디어 형식을 사용해서 통신할 지 알게 된다. 하지만 아직 어떻게 서로에게 도달할 수 있는 지는 모르는 상태이다.

 

이때 ICE가 사용된다. ICE는 STUN, TURN 서버 등을 사용해서 경로 후보(candidate)를 도출한다. 두 피어는 candidate를 교환하면서 상대에게 도달 가능한 경로를 찾는다. 서로 호환 되는 candidate를 찾았을 때 미디어 통신이 시작된다.

1. caller는 offer를 생성해 callee에게 전달한다. 이때 offer/answer은 SDP 형식을 갖는다.
2. callee가 offer를 수락하면 answer를 생성해 caller에게 다시 전달한다.
3. SDP 교환 후, 두 피어는 ICE candidate를 교환하기 시작한다.
4. 서로 호환되는 candidate가 제안 됐을 때 미디어 통신이 시작된다.

 

---

WebRTC 아키텍처

 

Mesh (Peer-to-Peer)

• Mesh는 우리가 지금까지 알아본 P2P 통신과 동일하다. 별도의 중앙 서버 없이 피어 간 연결을 수립한다. 피어 수와 상관없이 각 피어는 다른 모든 피어와 1:1 연결을 맺는다.
• 구현이 간단하며 P2P인 만큼 지연 시간(latency)을 최소화할 수 있다.
• 피어가 늘어날수록 트래픽이 증가하고 연결이 불안정해질 수 있다.

 

 

SFU (Selective Forwarding Unit)

• SFU는 중앙 서버가 존재한다.
• 모든 피어가 서버로 미디어 스트림을 보내면 서버는 수신한 스트림 중 선택적으로 스트림을 전송할 수 있다.
• 스트림을 개별적으로 관리할 수 있다. 피어 별로 네트워크 환경에 따라 비디오 품질을 조정하거나 서로 다른 코덱을 사용할 수 있다.
• Mesh보다 안정적이면서도 비슷한 수준의 실시간성을 유지할 수 있다.

 

 

MCU(Multi-point Control Unit)

• MCU도 중앙 서버가 존재한다.
• 모든 피어가 서버로 미디어 스트림을 보내고 서버는 수신된 모든 미디어 스트림을 하나로 병합하여 다시 전송한다.
• 중앙 집중식으로 가장 안정적이며 대역폭을 효율적으로 관리할 수 있다.
• 높은 서버 비용이 필요하고 설정 및 유지 관리가 복잡하다.
• 실시간성이 저해될 수 있다.

 

→ SFU는 각 피어의 스트림을 개별적으로 관리하고, MCU는 하나의 스트림으로 병합 및 관리한다.
→ SFU은 스트림을 포워딩하기만 하고, MCU는 스트림을 병합하여 전송한다.

 

 

---

마무리

내가 맡은 프로젝트의 요구사항은 두 가지이다.

• 1:N 또는 소수:다수 의 화상 통신을 지원한다.
• 1(소수) 측은 영상 수신만, 다수 측은 송신만 요구된다.

 

따라서 내가 결정한 방식은 실시간성을 가져가면서도 선택적 관리가 가능한 SFU다! SFU을 지원하는 다양한 라이브러리가 있는데 그중 mediasoup를 선택했다. 다음 시간에는 mediasoup에 대해 정리해보고자 한다.

 

참고 및 사진 출처

🔗 https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API
🔗 https://getstream.io/blog/what-is-a-selective-forwarding-unit-in-webrtc/
🔗 https://developer.liveswitch.io/liveswitch-cloud/index.html