WebRTC LiveKit 연동 회고: 그냥 오픈소스 서버 띄우면 되는 거 아니야?

실시간 음성 매칭 서비스 VoiceLink를 구축할 때, 가장 까다로운 난제는 로컬 개발 환경과 실제 모바일 LTE/사내 방화벽 환경 간의 네트워크 도달률 차이였습니다.

“WebRTC? 그냥 오픈소스 LiveKit 도커로 띄우고 클라이언트 SDK 연결하면 끝 아닌가?”

로컬 환경에서는 즉시 연결되던 통화가 실제 사용자 모바일 LTE 환경이나 대칭형 NAT(Symmetric NAT) 환경에서 연결 지연 및 미디어 패킷 유실이 발생했습니다. 이를 해결하기 위해 Coturn 기반 STUN/TURN 릴레이 아키텍처와 LiveKit SFU 미디어 서버 연동을 고도화했습니다.


1. NAT 방화벽 투과 및 ICE Candidate 메커니즘

WebRTC는 P2P 연결을 위해 ICE(Interactive Connectivity Establishment) 프레임워크를 사용합니다. 일반적인 환경에서는 STUN을 통해 공인 IP를 바인딩하지만, 방화벽이 엄격한 Symmetric NAT 환경에서는 TURN 릴레이 서버를 경유하도록 Fallback 경로를 필수적으로 구성해야 합니다.

flowchart TD
    ClientA["Client A (Mobile LTE)"] --> ICE{"ICE Candidate 수집"}
    ICE -- "1. Host / Server Reflexive" --> STUN["STUN 바인딩 시도"]
    STUN -- "Direct P2P 가능" --> DirectPeer["Direct Media Stream"]
    STUN -- "Symmetric NAT 차단" --> TURN["Coturn Relay (TURN Server 경유)"]
    TURN --> LiveKitSFU["LiveKit SFU 미디어 서버"]
    LiveKitSFU --> ClientB["Client B (Web/Mobile)"]

2. 5초 단위 Redis Timeline 통화 품질 모니터링

클라이언트와 LiveKit Webhook에서 수신되는 패킷 손실률(Packet Loss), RTT(Round Trip Time), Jitter 수치를 Redis Timeline 구조로 5초 단위 수집하여 통화 품질 저하 구간을 실시간으로 감지하도록 구성했습니다.


3. 연관 아티클 및 실무 링크


📚 공식 레퍼런스 (References)

댓글 남기기