RTCP Sender Report, 지터, 패킷 손실: 비디오를 시청하지 않고 스트림 상태 읽기

RTCP sender report와 RTP 타이밍 증거가 비디오 재생에 의존하지 않고 RTSP 카메라 스트림 상태를 진단하는 데 어떻게 도움이 되는지.

RTCP, RTP, RTSP, jitter, packet loss

엔지니어가 "RTSP jitter", "RTP packet loss", 또는 "RTCP sender report"를 검색할 때, 그들은 보통 실질적인 질문에 대한 답을 찾고 있습니다: "스트림이 불안한 것인가, 플레이어가 어려움을 겪는 것인가? 비디오 재생은 늦은 증상입니다. RTP와 RTCP 증거는 더 일찍 나타나며 지원 사례에서 방어하기 쉽습니다." RTCP는 RTP의 제어 동반자입니다. sender report, receiver report, 패킷 수, 타이밍 정보, 품질 피드백을 전달할 수 있습니다. 모든 카메라가 풍부한 RTCP 동작을 노출하는 것은 아니며, 모든 배포 환경이 올바르게 전달하는 것도 아니지만, RTCP가 존재할 때 원시 재생이 제공하지 않는 중요한 컨텍스트를 제공합니다.

카메라 진단에서 RTCP가 중요한 이유

RTP는 미디어 패킷을 전달합니다. RTCP는 미디어 세션 상태를 설명하는 데 도움이 됩니다. RTSP 카메라 스트림의 경우, RTCP 증거는 다음 질문에 답하는 데 도움이 됩니다:

  • PLAY 이후 sender가 살아 있습니까?
  • sender report에서 몇 개의 RTP 패킷을 보고했습니까?
  • RTP 타임스탬프가 월 클럭 타이밍과 정렬되어 있습니까?
  • 패킷 전달이 안정적인가요 아니면 버스트한가요?
  • 보이는 지터가 있습니까?
  • 비디오 디코딩이 실패하는 동안 RTP가 계속되었습니까?
  • 미디어 경로에 RTCP가 포함되었습니까?

RTSP 제어가 성공하고 RTP가 도착하지만 비디오가 정지되면, RTCP는 네트워크 타이밍과 코덱 준비 상태를 분리하는 데 도움이 됩니다.

Sender Report는 타이밍 증거입니다

RTCP sender report는 RTP 타임스탬프를 절대 NTP 스타일 시간 값과 관련시킬 수 있습니다. 이 관계는 수신기가 스트림을 동기화하고 클럭 동작에 대해 추론하는 데 도움이 됩니다. 진단에서 정확한 수식보다 보고서의 존재와 일관성이 더 중요할 수 있습니다.

유용한 관찰:

  • 미디어 시작 후 sender report가 나타남
  • 패킷 및 옥텟 수가 증가
  • RTP 타임스탬프 매핑이 일관됨
  • 보고 간격이 타당함
  • RTP가 멈추면 보고서도 멈춤
  • 디코더가 실패하는 동안에도 보고서가 계속됨

RTCP가 RTP와 함께 멈추면 sender나 미디어 경로가 중단되었을 수 있습니다. RTCP는 계속되지만 비디오 디코딩이 실패하면 페이로드와 코덱 증거를 검사하세요.

지터는 패킷 손실과 동일하지 않습니다

지터는 패킷이 가변적인 타이밍으로 도착한다는 의미입니다. 패킷 손실은 패킷이 누락되었다는 의미입니다. 둘 다 보이는 끊김을 유발할 수 있지만, 다른 해결책으로 이어집니다.

RTP 시퀀스 번호는 누락된 패킷을 보여줍니다. RTP 타임스탬프와 도착 시간은 타이밍 변동을 보여줍니다. RTCP 보고서는 세션 레벨 피드백을 추가할 수 있습니다. 적절한 보고서는 단순히 "나쁜 네트워크"라고만 하면 안 됩니다. 문제가 손실인지, 지터인지, 버스트 전달인지, 차단된 RTCP인지, 또는 코덱 디코드 경계인지를 말해야 합니다.

카메라의 경우, 지터는 다음에서 발생할 수 있습니다:

  • Wi-Fi 업링크 변동
  • 과부하된 카메라 인코더
  • NVR 전달 지연
  • 혼잡한 스위치 경로
  • VPN 또는 WAN 경로
  • 클라이언트 측 버퍼링 동작

패킷 손실은 다음에서 발생할 수 있습니다:

  • UDP 드롭
  • 방화벽/NAT 동작
  • 과부하된 네트워크
  • 카메라 송신 버퍼 압력
  • 캡처 지점 제한

해결책은 다릅니다.

RTCP 누락도 증거입니다

일부 배포 환경은 RTP가 흐르더라도 RTCP를 차단합니다. 일부 카메라는 유용한 RTCP를 보내지 않습니다. 일부 클라이언트는 절대 명확하게 요청하거나 수신하지 않습니다. RTCP가 누락되었다고 해서 자동으로 스트림이 깨졌다는 의미는 아니지만, 기록되어야 합니다.

UDP 위의 RTP가 협상되면 미디어와 제어 동반 트래픽을 모두 검사하세요. TCP interleaved 위의 RTSP가 사용되면 interleaved 채널 메타데이터를 검사하세요. "RTP 보임, RTCP 없음"이라고 말하는 보고서는 빈 필드보다 더 유용합니다.

RTSP Inspector가 적합한 곳

RTSP Inspector는 수동 시청이 아닌 프로토콜 증거를 위해 만들어졌습니다. RTCP는 RTSP 메서드, SDP, RTP 시퀀스 연속성, 페이로드 타입, 코덱 메타데이터, 보고서 내보내기와 같은 이야기의 일부입니다.

RTCP 중심 검색의 경우, RTSP Inspector는 다음 질문에 답하는 데 도움이 됩니다:

  • PLAY 이후 RTP가 도착했습니까?
  • RTCP sender report가 나타났습니까?
  • 패킷 수가 증가했습니까?
  • 보이는 실패와 지터 또는 시퀀스 갭이 정렬되었습니까?
  • 미디어 전달에도 불구하고 코덱 준비가 실패했습니까?
  • 전송 모드가 상태 프로필을 변경했습니까?

이는 카메라 벤더, 네트워크 엔지니어, 또는 VMS 개발자에게 구체적인 출발점을 제공합니다. "스트림이 끊긴다"는 증상입니다. "RTSP 제어가 살아 있는 동안 PLAY 이후 RTP 시퀀스 갭과 지터가 증가했다"는 증거입니다.