LiveKit with WebRTC

1. WebRTC와 LiveKit의 관계

• WebRTC는 브라우저 및 앱에서 실시간 오디오 비디오 데이터 통신을 위한 표준 기술이다. WebRTC 공식 사이트: webrtc.org
• LiveKit은 WebRTC를 기반으로 멀티 유저 실시간 앱을 만들기 위한 플랫폼이다. LiveKit 서버는 WebRTC 기반 SFU로 동작한다.
  • LiveKit 소개: Intro to LiveKit
  • LiveKit SFU 내부: LiveKit SFU

즉, LiveKit은 WebRTC를 대체하기보다 WebRTC 위에 룸 모델, 권한, 구독 제어, 확장 기능을 제공하는 레이어에 가깝다.

2. 왜 SFU가 필요한가

2.1 순수 WebRTC P2P 메시의 한계

N명이 모두 P2P로 직접 연결하면 일반적으로 각 클라이언트는 N-1개의 연결을 유지해야 해서 업로드 대역폭과 CPU 부담이 커진다.

A ←→ B
A ←→ C
A ←→ D
B ←→ C
...

2.2 LiveKit의 방식

• 각 클라이언트는 SFU로 한 번만 업로드
• SFU가 다른 참가자에게 트랙을 선택적으로 전달
• 네트워크 상태에 따라 품질 레이어를 조절할 수 있도록 Simulcast 등을 지원한다
  • LiveKit 고급 미디어: Codecs and more

      A
      ↓↑
      SFU
  ↓↑   ↓↑   ↓↑
 B     C     D

---

3. WebRTC 핵심 구성 요소

3.1 RTCPeerConnection

• RTCPeerConnection은 로컬 피어에서 원격 피어와의 WebRTC 연결을 표현하는 핵심 API다.
  • webrtc.org 가이드: Getting started with peer connections
  • MDN: RTCPeerConnection

중요한 개념:

• 연결은 논리적으로 A와 B 사이에 성립하지만, 객체 인스턴스는 각 피어에 하나씩 존재한다
• RTCPeerConnection A, RTCPeerConnection B가 각각 있으며 signaling으로 SDP와 ICE 후보를 교환해 연결을 성립시킨다
  • webrtc.org: Peer connections

3.2 MediaStream과 MediaStreamTrack

• 카메라 마이크 입력은 보통 getUserMedia로 얻고, 결과는 MediaStream이다
• 실제로 전송에 사용되는 단위는 MediaStreamTrack이며, 트랙을 addTrack로 RTCPeerConnection에 붙여 전송한다

3.3 RTCDataChannel

• RTCDataChannel은 임의 데이터 전송을 위한 채널이다
• 데이터 채널 추가 흐름: MDN Using WebRTC data channels
• webrtc.org: Data channels

---

4. 구조와 연결 흐름을 한 장으로

아래 다이어그램은 다음을 한 번에 표현한다.

• 각 피어 내부에 RTCPeerConnection과 미디어 트랙, 데이터 채널이 연결되는 구조
• RTCPeerConnection A와 B 사이에서 signaling, ICE, DTLS, 미디어, 데이터가 오가는 흐름
• 예시로 A가 B로 audio video를 보내고 B가 A로 file을 보낸다고 가정

flowchart LR
   Signaling server for SDP and ICE exchange
  SIG[Signaling server SDP and ICE exchange]

   Between PeerConnections
  PCA <-->|ICE connectivity checks| PCB
  PCA <-->|DTLS handshake| PCB

   Peer B mirrored, App at far right
  subgraph PeerB[Peer B]
    direction LR
    PCB[RTCPeerConnection B]
    AT_B[MediaStreamTrack audio]
    VT_B[MediaStreamTrack video]
    MSB[MediaStream]
    DCB[RTCDataChannel]
    AppB[App]

    PCB -->|ontrack| AT_B
    PCB -->|ontrack| VT_B
    AT_B --> MSB
    VT_B --> MSB
    MSB --> AppB

    PCB -->|ondatachannel| DCB
    DCB <-->|file send and onmessage| AppB
  end

다이어그램에서 이벤트가 의미하는 것

• ontrack은 원격에서 들어온 트랙이 RTCPeerConnection에 추가된 뒤 발생하는 이벤트다
  • MDN: RTCPeerConnection track event
• ondatachannel은 원격 피어가 createDataChannel로 만든 채널이 연결에 추가될 때 발생하는 이벤트다
  • MDN: Using WebRTC data channels

---

5. 연결이 성립되는 순서

이 섹션은 위 다이어그램을 시간 흐름으로 요약한다.

1. SDP 협상

• offer를 만들고 local description에 설정한 뒤 signaling으로 전달
• 상대는 remote description으로 적용하고 answer를 만들어 다시 전달
• webrtc.org: Getting started with peer connections

2. ICE 후보 교환

• ICE 후보는 icecandidate 이벤트로 생성되며 signaling으로 전달한다
• 상대는 후보를 받아 addIceCandidate로 적용한다
• webrtc.org: Getting started with peer connections

3. ICE connectivity checks와 DTLS

• ICE가 후보 쌍을 검사하고 최적 경로를 선택한다. ICE는 STUN과 TURN을 사용한다
  • RFC: RFC 8445 ICE
• 이후 DTLS 핸드셰이크로 보안 연결을 성립한다. DataChannel은 DTLS로 보호된다
  • MDN: Using WebRTC data channels

---

6. 예시 3개 흐름

6.1 A에서 B로 audio 전달

• A는 마이크 트랙을 addTrack으로 RTCPeerConnection A에 추가한다
• 연결이 성립되면 B의 RTCPeerConnection B에서 ontrack으로 audio 트랙을 받는다
• MDN: track event

6.2 A에서 B로 video 전달

• A는 카메라 트랙을 addTrack으로 추가한다
• B는 동일하게 ontrack으로 video 트랙을 수신한다
• MDN: track event

6.3 B에서 A로 file 전달

• 파일 전송은 RTCDataChannel을 사용한다. 파일을 chunk로 나눠 send로 전송하고 상대는 message로 수신한다
• 수신 측 데이터 채널은 RTCPeerConnection의 ondatachannel 이벤트로 전달된다
• MDN: Using WebRTC data channels
• webrtc.org: Data channels

---

7. ICE STUN TURN 개념과 예시

7.1 개념 요약

• ICE는 NAT 환경에서 통신 경로를 찾기 위해 후보를 수집하고 검사해 경로를 선택하는 절차다. ICE는 STUN과 TURN을 사용한다
  • RFC: RFC 8445 ICE
• STUN은 NAT 뒤의 엔드포인트가 외부에서 관측되는 주소 정보를 얻거나 연결성 검사를 돕는 프로토콜이다
  • RFC: RFC 8489 STUN
• TURN은 직접 연결이 불가능할 때 릴레이 서버를 통해 패킷을 전달하는 프로토콜이다
  • RFC: RFC 8656 TURN

7.2 예시로 이해하기

• 같은 LAN 환경
  • host 후보만으로도 연결되는 경우가 많다
• 서로 다른 집 환경
  • STUN을 이용해 외부에서 보이는 주소 후보를 얻고 직접 연결을 시도할 수 있다
• 엄격한 방화벽 또는 대칭 NAT 환경
  • 직접 연결이 실패하면 TURN 릴레이 후보를 통해 통신한다

8. LiveKit 핵심 개념

LiveKit 기본 모델은 Room Participant Track이다.

• LiveKit: Rooms, participants, and tracks overview
• LiveKit: Subscribing to tracks

Token이 필요한 이유

LiveKit SDK가 서버에 연결하려면 access token이 필요하며, 토큰에는 참가자 identity, room 이름, publish subscribe 권한 등이 포함된다. 토큰은 JWT 기반이며 API secret으로 서명된다.

• LiveKit: Tokens overview
• LiveKit: Authentication overview

---

참고 문서

WebRTC

• WebRTC 공식: https://webrtc.org/
• webrtc.org Peer connections: https://webrtc.org/getting-started/peer-connections
• webrtc.org Data channels: https://webrtc.org/getting-started/data-channels
• W3C WebRTC 1.0: https://www.w3.org/TR/webrtc/

MDN Web APIs

• RTCPeerConnection: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection
• RTCPeerConnection addTrack: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/addTrack
• RTCPeerConnection track event: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/track_event
• Using WebRTC data channels: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels
• MediaStream: https://developer.mozilla.org/en-US/docs/Web/API/MediaStream
• MediaStreamTrack: https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack
• getUserMedia: https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia

ICE STUN TURN RFC

• ICE: https://www.rfc-editor.org/rfc/rfc8445
• STUN: https://www.rfc-editor.org/rfc/rfc8489.html
• TURN: https://www.rfc-editor.org/info/rfc8656

LiveKit

• Intro: https://docs.livekit.io/intro/
• Room Participant Track overview: https://docs.livekit.io/intro/basics/rooms-participants-tracks/
• Subscribing to tracks: https://docs.livekit.io/transport/media/subscribe/
• Advanced media: https://docs.livekit.io/transport/media/advanced/
• Tokens: https://docs.livekit.io/frontends/authentication/tokens/
• Authentication: https://docs.livekit.io/frontends/authentication/
• LiveKit SFU internals: https://docs.livekit.io/reference/internals/livekit-sfu/