요약

  • RTP의 시퀀스 번호는 전송된 패킷의 순서를 정하고, 타임스탬프는 포맷별 샘플링 또는 프레젠테이션 클록 위에서 미디어의 위치를 지정합니다. 어느 필드도 패킷의 절대 전송 시각에 대한 영수증이 아닙니다.
  • 서로 다른 스트림은 RTP 카운터와 NTP 형식 참조값을 짝지은 간헐적 RTCP Sender Report를 통해 공통 시간을 얻습니다. 증거가 되는 것은 원시 숫자 사이의 유사성이 아니라 그 매핑입니다.

비디오 인코더가 하나의 그림을 여러 네트워크 패킷으로 나누는 상황을 상상해 보십시오. 패킷은 어떤 순서로 나가야 하므로 RTP 시퀀스 번호가 하나씩 증가합니다. 그러나 모든 조각은 같은 샘플링된 프레임에 속하므로 패킷들이 같은 RTP 타임스탬프를 지닐 수 있습니다. 모순은 없습니다. 두 필드는 서로 다른 질문에 답하고 있습니다.

그 구분은 Henning Schulzrinne, Stephen Casner, Ron Frederick, Van Jacobson이 작성한 실시간 전송 프로토콜(RTP)의 중심부에 가깝습니다. RFC 1889는 1996년에 이 표준을 발표했고, RFC 3550은 2003년에 와이어상의 패킷 포맷을 바꾸지 않고 이를 개정했습니다. 여기서 Casner가 주제인 이유는 USC Information Sciences Institute가 그를 RTP의 개발과 표준화를 이끈 인물로 평가하기 때문이지, 협업 프로토콜을 단독 발명가 이야기로 다시 써야 하기 때문이 아닙니다.

그들이 보존한 구분은 현대 텔레메트리에서 쉽게 잃어버릴 수 있습니다. 어떤 필드의 이름이 “타임스탬프”이면 분석가는 그것이 보편적인 순간을 가리킨다고 가정합니다. 시퀀스가 증가하면 대시보드는 미디어도 그렇게 했다고 가정합니다. RTP는 두 지름길 모두에 저항합니다. RTP가 제공하는 것은 한계 자체가 설계의 일부인 작은 증거 조각들입니다.

하나의 카운터는 패킷을 따르고, 다른 하나는 미디어를 따른다

16비트 시퀀스 번호는 전송되는 모든 RTP 데이터 패킷마다 증가합니다. 수신자는 이를 사용해 공백을 감지하고 패킷 순서를 재구성할 수 있습니다. 초기값은 무작위이므로, 이렇게 단순해 보이는 카운터조차 1에서 시작하는 세션 전체의 일련번호가 아닙니다. 이는 한 소스가 전송한 패킷 시퀀스 안에서의 위치를 설명합니다.

32비트 타임스탬프는 다른 클록을 따릅니다. RFC 3550은 이를 패킷에 실린 첫 옥텟의 샘플링 순간으로 정의합니다. 패킷이 주기적으로 생성될 때 그 값은 공칭 샘플링 클록에서 나오며, 패킷이 소켓을 지나갈 때 시스템 클록을 읽어서 나오는 것이 아닙니다. 그 속도는 페이로드 포맷에 따라 달라집니다.

고정 레이트 오디오에서 160개의 샘플링 주기를 담은 블록은 타임스탬프를 160만큼 진행시킵니다. 그 블록이 무음으로 드롭될 때도 같은 양만큼 진행합니다. 패킷이 무음 구간을 운반하지 않더라도 미디어 타임라인은 계속됩니다. RTP 값을 패킷 발송 시각으로 취급하면, 바로 그 값이 보존하려고 선택된 연속성이 지워집니다.

비디오는 이 규칙의 다른 면을 드러냅니다. 하나의 프레임을 구성하는 여러 패킷은 논리적으로 하나의 미디어 순간에 생성되었기 때문에 같은 타임스탬프를 공유할 수 있습니다. 인코딩된 프레임은 샘플링된 순서와 다른 순서로 전송될 수도 있습니다. 시퀀스 번호는 여전히 전송과 함께 증가하지만, 연속된 타임스탬프는 비단조적으로 움직일 수 있습니다. 그런 패턴을 보여주는 캡처만으로는 네트워크 재정렬이나 고장 난 클록이 입증되지 않습니다.

RTP는 초기 타임스탬프도 무작위화합니다. 따라서 900000 같은 원시 값은 그 자체로 달력적 의미를 지니지 않습니다. 운영자가 이를 초로 변환하려면 페이로드의 클록 레이트가 필요합니다. 다른 스트림과 비교하려면 그 출처와 오프셋을 알아야 합니다. 공통 타임라인에 올리려면 매핑이 필요합니다.

오디오와 비디오는 숫자의 유사성만으로 동기화될 수 없다

오디오 스트림과 비디오 스트림이 같은 물리적 순간에 캡처되었더라도, 서로 무관해 보이는 카운터를 보고할 수 있습니다. 두 스트림의 클록 레이트는 다를 수 있고, 각각은 보통 독립적인 무작위 오프셋에서 시작합니다. 따라서 RFC 3550은 두 스트림의 RTP 타임스탬프를 직접 비교하는 것이 동기화에 효과적이지 않다고 말합니다.

이는 데이터 패킷에 과부하를 주지 않으려는 의도적 거부입니다. 미디어별 클록은 하나의 스트림을 정렬하고 샘플링 리듬에 대한 도착 변동을 계산하는 데 탁월합니다. 그러나 보편적 클록으로는 부적합합니다. 모든 곳에서 이를 절대적으로 만들면 빠른 데이터 경로가 많은 애플리케이션에 필요 없는 시간 원천과 표현에 묶이게 됩니다.

대신 송신자는 주기적으로 RTCP Sender Report를 생성합니다. 이 보고서는 같은 순간에 해당하는 RTP 타임스탬프 옆에 NTP 형식 참조 타임스탬프를 둡니다. 그 쌍은 로컬 미디어 카운터와 참조 시간 사이의 관계를 정의합니다. 그런 다음 오디오와 비디오는 각자의 매핑을 공유 클록에 적용해 함께 배치될 수 있습니다.

그 쌍들은 의도적으로 드물게 나타납니다. 모든 RTP 데이터 패킷에 복사되지 않습니다. 수신자는 카운터 레이트와 참조 시간 사이의 알려진 관계로부터 보간합니다. Sender Report의 RTP 값은 보통 인접한 미디어 패킷의 타임스탬프와 같지 않습니다. 그 값은 보고서의 참조 순간을 위해 계산되기 때문입니다. 정확히 이웃한 숫자를 찾는 도구는 올바른 매핑을 거부할 수 있습니다.

그 매핑에는 익숙한 포맷이 감출 수 있는 경계도 있습니다. RFC 3550은 절대 시간이 없는 송신자가 시스템 가동 시간처럼 흔히 이용 가능한 상대 클록을 NTP 형식 필드에 사용하도록 허용합니다. 벽시계 지식도 경과 시간 지식도 없는 송신자는 이 값을 0으로 설정할 수 있습니다. NTP처럼 생긴 64비트가 자동으로 UTC 정확도의 증거가 되는 것은 아닙니다.

RFC 7273은 나중에 이 모델을 클록 신호 방식으로 명시했습니다. RTCP Sender Report의 NTP/RTP 쌍은 매핑을 정의하지만, 소스 간 시간 정렬 재생은 그 자체로 동기화된 참조 타임스탬프에 여전히 의존합니다. 이 보고서는 상관관계 영수증입니다. 이름을 붙였다는 이유만으로 기반 클록을 개선하지는 않습니다.

타이밍 설계는 장식적 메타데이터가 아니라 제약된 미디어에서 나왔다

Casner가 이 문제에 들어선 경로는 ARPANET의 패킷 음성에서 시작되었습니다. ISI의 설명은 연속 오디오를 압축하고, 패킷으로 나누고, 심각한 대역폭 제한 아래에서 다른 쪽 끝에서 재구성해야 했던 작업을 다룹니다. 그는 이후 패킷 비디오 작업을 했고, MBONE 멀티캐스트 실험의 설립을 도왔으며, RTP 개발과 표준화를 이끌었습니다. 이 기관의 추도문은 RTP를 ISI의 Network Voice Protocol과 Packet Video Protocol로 거슬러 올라가게 합니다.

그 역사는 왜 이 필드들이 경제적인지 설명하는 데 도움을 줍니다. RTP는 대역폭, 자원 예약, 서비스 품질을 약속하지 않습니다. 대신 애플리케이션이 사용할 수 있는 식별자, 시퀀스, 미디어 시간, 전달 보고서를 제공합니다. 네트워크는 패킷을 지연시키거나 드롭하거나 재정렬할 수 있습니다. 수신자는 여전히 재생 가능한 타임라인을 복구할 만큼의 구조와 그 한계를 이해할 만큼의 제어 증거를 필요로 합니다.

2003년 개정은 같은 규율을 보여줍니다. RFC 3550은 와이어 패킷 포맷이 RFC 1889에서 바뀌지 않았다고 말합니다. 가장 큰 변경은 많은 참여자가 합류할 때 RTCP 전송을 관장하는 확장 가능한 타이머 알고리즘이었습니다. 데이터 경로의 어휘는 안정적으로 유지되었고, 증거를 얼마나 자주 보고할 수 있는지를 둘러싼 제어 시스템이 개선되었습니다.

그 결과는 모든 패킷에 내장된 마법의 시계가 아닙니다. 일련의 분리입니다. 시퀀스는 전송을 세고, 타임스탬프는 미디어를 따르며, SSRC는 소스의 범위를 정합니다. RTCP는 전달을 보고하고 때때로 참조 매핑을 제공합니다. 애플리케이션이 이 조각들이 어떻게 재생으로 이어질지 결정합니다.

캡처에는 그것이 나온 클록 도메인이 필요하다

32비트 타임스탬프만 저장하는 관측 시스템은 이미 핵심 증거를 버린 것입니다. SSRC, 페이로드 포맷, 타임스탬프 클록 레이트, 시퀀스 번호, 캡처 시간, 가장 가까운 유효 RTCP RTP/NTP 쌍을 보존해야 합니다. 또한 참조값이 절대적인지, 상대적인지, 아니면 부재인지 알 수 있는 경우에는 이를 기록해야 합니다.

그 영수증이 있으면 조사자는 여러 실패를 구분할 수 있습니다. 빠진 시퀀스 번호는 패킷 손실을 나타낼 수 있습니다. 타임스탬프 불연속은 소스 재시작, 페이로드 클록 변경, 프레젠테이션 점프를 표시할 수 있습니다. 매핑된 오디오와 비디오 시간 사이의 차이가 커지면 드리프트를 나타낼 수 있습니다. Sender Report 사이의 긴 간격은 미디어 카운터 자체에 대해서는 아무 말도 하지 않으면서 상관관계를 불확실하게 만들 수 있습니다.

영수증이 없으면 변환은 추측이 됩니다. 모든 타임스탬프를 90,000으로 나누는 것은 적용되지 않을 수도 있는 비디오 클록을 조용히 가정합니다. 타임스탬프로 정렬하는 것은 전송 순서 대신 샘플링 순서를 조용히 대입합니다. 두 원시 스트림을 비교하는 것은 동일한 레이트와 오프셋을 조용히 가정합니다. NTP 모양의 값을 UTC로 출력하는 것은 표현을 보증으로 조용히 승격시킵니다.

Casner의 프로토콜 작업은 증거 시스템에 오래 유지되는 규칙을 제공합니다. 가장 편리한 필드가 전체 이야기를 떠안게 하지 마십시오. 좁은 필드가 여러 애플리케이션에서 안정적으로 유지될 수 있는 것은 더 넓은 의미로의 매핑이 명시적이고, 간헐적이며, 검증 가능하기 때문입니다.

출처