RTCP 완전정복

RTP만으로는 영상이 끊겨도 모릅니다. 수신 품질을 피드백하는 RTCP의 핵심 메시지 4종 — SR, RR, NACK, PLI를 실제 동작 흐름으로 설명합니다.

RTCP 완전정복 시리즈 #2 P2P 통화는 단순하다. A가 B에게 영상을 보내고, B가 "잘 받고 있어" 또는 "패킷 좀 빠졌어"라고 A에게 알려준다. 지난 편에서 다룬 SR, RR, NACK, PLI — 이 피드백들이 A와 B 사이를 직접 오가면 끝이다. 그런데

SFU가 Sender Report를 직접 생성하면 jitter buffer가 폭주합니다. 왜 SR은 '생성'이 아니라 '번역'이어야 하는지, 실제 버그 사례와 함께 설명합니다.

RTCP 완전정복 시리즈 #4 1편에서 PLI(Picture Loss Indication)를 설명하면서 한 줄을 남겨뒀다. "PLI는 공짜가 아니다." PLI는 "화면이 깨졌으니 키프레임을 보내달라"는 요청이다. 받는 쪽 입장에서는 응급 처치다. 키프레임이 오면 깨진 화면이 즉시 복구된다. 그래서 문제가 생기면 PLI를 보내는 게 자연스럽다. 문제는,...

SR/RR은 5초마다 건강검진을 하지만, TWCC는 패킷 하나하나의 도착 시간을 추적합니다. WebRTC 대역폭 추정의 실제 동작 원리와 SFU에서의 역할을 설명합니다.