<aside>

</aside>

은서

일반적인 미디어 서버의 흐름

1. 유저가 SDP를 생성한다.

   <aside>

   SDP는 멀티미디어 세션을 위한 프로토콜로, webRTC에서 미디어 스트림의 속성을 설명하기 위한 핵심 프로토콜이다. 비디오/오디오 코덱, 네트워크 정보, 대역폭 정보, 보안 정보 등을 교환하는 역할을 한다.

   </aside>

   • 브라우저에서 getUserMedia()로 카메라/마이크 접근 권한을 요청한다.
   • new RTCPeerConnection()으로 연결 객체를 생성한다.
   • createOffer()를 호출하여 자신의 미디어 정보가 담긴 SDP를 생성한다.

2. websocket 등으로 구현된 시그널링 서버를 통해 유저끼리 SDP를 교환한다.

   • 시그널링 서버는 각 클라이언트 간의 메시지를 중계한다.
   • A가 생성한 SDP(offer)를 서버를 통해 B에게 전달한다.
   • B는 이를 받아 자신의 SDP(answer)를 생성하여 A에게 전달한다.

3. 미디어 권한을 획득한다.

   • 실제 카메라/마이크 사용 권한을 브라우저에서 요청한다.
   • 사용자가 권한을 허용하면 미디어 스트림을 얻을 수 있다.

4. NAT 환경을 대비해 ICE Candidate를 수집하고 다시 한번 교환한다.

   <aside>

   • NAT은 사설 IP 주소를 공인 IP 주소로 변환해주는 기술이다.

   • ICE는 NAT 환경에서 두 단말간 통신 가능한 경로를 찾아주는 프레임워크이다.

   • STUN 서버는 NAT 뒤에 있는 클라이언트가 자신의 공인 IP와 포트를 알아낼 때 사용한다.

   • TURN 서버는 P2P 연결이 불가능할 때 사용하는 중계 서버이다. </aside>

   • NAT 환경에서는 직접적인 P2P 연결이 어려울 수 있다.

   • ICE 프로세스가 시작된다.

   • STUN/TURN 서버를 통해 자신의 공인 IP 주소를 알아내고, 가능한 모든 연결 경로 (ICE Candidate)를 수집한다.

   • 수집된 Candidate들도 시그널링 서버를 통해 상대방과 교환한다.

5. 미디어 서버(SFU)와 SDP를 교환한다.

   • SFU는 중앙 미디어 서버이다.
   • 각 클라이언트는 SFU와 WebRTC 연결을 맺는다.
   • 클라이언트는 자신의 미디어 스트림을 SFU에 전송한다.
   • SFU는 받은 스트림을 다른 참여자들에게 전달한다.

6. 미디어 스트림 전송을 시작한다.

   • SDP 교환과 ICE 과정이 완료되면 실제 미디어 전송이 시작된다.
   • 클라이언트 → SFU → 다른 클라이언트로 미디어가 전달된다.

mediasoup이란

음성 통화, 영상 통화 등 미디어를 다루는 미디어 서버를 편리하게 구축하게 해주는 미디어 서버 오픈 소스 라이브러리이다.

webRTC, SFU 기반 p2p 서버이기 때문에 낮은 지연률과 높은 확장성을 보장한다.

일반적인 미디어 서버와 다른 점은 다음과 같다.

시그널링 처리 방식

일반 webRTC는 시그널링 서버를 통해 P2P로 SDP를 교환하지만, mediasoup는 자체 시그널링 프로토콜을 제공하지 않기 때문에 개발자가 직접 구현해야 한다.

미디어 라우팅

일반 webRTC는 주로 P2P나 단순 중계를 하지만 mediasoup는 더 정교한 라우팅을 제공한다. 개별 트랙 레벨 제어, 동적 비디오 레이어 스위칭, 선택적 구독 등이 가능하다.