요약

  • RFC 3952는 하나 이상의 고정 크기 iLBC 프레임을 대역 내 프레임 개수 필드 없이 전송했으며, 수신기는 SDP를 통해 합의된 모드에 따라 RTP 페이로드 길이를 38 또는 50으로 나누었습니다.
  • 2026년에 보고된 정오표가 한 섹션의32/50제수를38/50으로 바꾸자고 제안합니다. 이 충돌은 패킷 바이트, 활성 협상 상태, 디코더 수용 여부, 들리는 재생이 각각 별개의 근거임을 보여줍니다.

사라진 개수, 지워지지 않은 사실

RTP 패킷은 정확한 길이, 규칙적인 순서 번호, 그럴듯한 타임스탬프를 갖고 도착하면서도 여전히 하나의 본질적 질문을 자기 밖에 남겨둘 수 있습니다. 페이로드를 어떻게 나누어야 하는가?RFC 3952는 인터넷 Low Bit Rate Codec인 iLBC에 대해 별도의 개수 필드를 두지 않는 방식으로 이 질문에 답했습니다. 프레임들은 이어 붙여졌고, 그 개수는 계산되었습니다.

코덱은 두 가지 고정 크기를 제공했습니다. 20밀리초 프레임은 38옥텟을 차지했고, 30밀리초 프레임은 50옥텟을 차지했습니다. 수신기가 모드를 알고 나면 산술이 경계를 되찾아 줍니다. 페이로드 길이를 예상되는 프레임 크기로 나누면 프레임 수가 나옵니다. 모드 30에서 100옥텟 페이로드는 두 프레임을 의미했습니다. 모드 20에서 76옥텟 페이로드 역시 두 프레임이었습니다. 생략된 필드가 개수를 알 수 없게 만든 것은 아니었습니다. 개수를 사전 합의에 의존하게 만든 것입니다.

이 구분이 바로 이 설계의 역사적 관심사입니다. 패킷은 길이의 근거를 담았고, 세션 기술은 모드의 근거를 담았습니다. 둘을 결합해야만 프레임 수가 나왔습니다. 어느 쪽 사실도 다른 쪽을 대신할 수 없었습니다.

모드는 제어 평면에 살았다

RFC 3952는 코덱을iLBC/8000의 동적 RTP 페이로드 타입에 매핑했습니다. 모드는 SDP에서a=fmtp매개변수로 별도로 이동했습니다. 매개변수가 없으면 기본값은 30밀리초였습니다. 문서는 그 결과가 양방향임을 강조했습니다. 양쪽 끝이 같은 모드를 사용해야 했습니다.

이 문서의 오퍼/앤서 규칙은 "20"과 "30"을 단순한 지속 시간으로만 취급하면 오해하기 쉽습니다. 오퍼러는 선호를 밝히고, 앤서러는 어느 쪽 값이든 이름을 붙일 수 있었으며, 공통 결과는 대역폭이 낮은 모드였습니다. 30밀리초 프레임은 매 20밀리초마다 38옥텟이 아니라 50옥텟을 쓰기 때문에, 두 혼합 예제는 모두 모드 30으로 귀결됩니다. 신호 처리 결정은 따라서 리듬뿐 아니라 이후 모든 페이로드가 해석될 제수까지 선택했습니다.

와이어 규칙들이 이 의존성을 강화했습니다. 프레임은 RTP 패킷 사이에서 분할될 수 없었습니다. 두 모드의 프레임은 한 패킷 안에서 섞일 수 없었습니다. 집계는 전송 MTU로 한정되었고, 패킷당 프레임 수는 헤더 오버헤드와 지연, 그리고 하나의 데이터그램으로 잃게 되는 음성량 사이에서 균형을 맞췄습니다. 이 제약들 덕분에 길이 산술이 실현 가능했지만, 스스로를 설명하게 되지는 않았습니다.

38이 있어야 할 곳에 32가 나타났다

RFC 3952의 2장과 3.1절은 20밀리초 표현을 38옥텟으로 식별합니다. 코덱을 정의하는RFC 3951도 그 패킷화 크기와 일치합니다. 그런데 3.2절은 수신기가 프레임당 예상 옥텟으로 나눈다고 하면서32/50이라고 인쇄합니다.

RFC Editor 정오표 기록에는 이제 2026년 4월 3일에 제출된 정오표 ID 8866이 있고,38/50을 제안합니다. 그 상태는 Reported입니다. 이 상태가 중요합니다. 보고된 정오표는 충돌이 확인되고 수정이 제안되었다는 근거이며, 공식 검증된 수정과 같지 않습니다. 내부적으로 일관된 읽기가 강력하지만, 편집상의 확신을 절차 완료로 잘못 표기해서는 안 됩니다.

이 오류가 의미심장한 이유는 페이로드가 개수를 담지 않았기 때문입니다. 주변 규칙을 구현한 수신기라면 프레임 크기가 38임을 알았을 것입니다. 고립된 문장만 복사한 도구는 32를 물려받아 정상 패킷을 거부하거나, 불가능한 경계를 만들어 내거나, 오해를 부르는 진단을 출력할 수 있습니다. 패킷 바이트는 그대로입니다. 해석 계층만 틀립니다.

나누어 떨어짐은 필요 조건, 결코 충분 조건이 아니었다

활성 모드가 20밀리초이고 페이로드가 114옥텟이라고 가정해 봅시다. 38로 나누면 나머지 없이 세 프레임이 됩니다. 이는 유용한 프레임링 근거입니다. 하지만 각 38옥텟 블록이 유효한 iLBC인지, 발신자가 권한을 받았는지, SRTP 인증이 성공했는지, 지터 버퍼가 패킷을 받아들였는지, 디코딩이 수용할 만한 음성을 만들었는지, 실제로 누군가 들었는지는 증명하지 못합니다.

반대의 경우도 주의가 필요합니다. 활성 제수와 맞지 않는 길이는 변형된 미디어, 낡은 협상 상태, 페이로드 타입 혼동 또는 캡처 오류의 강한 근거입니다. 그러나 어떤 길이는 38과 50 둘 다로 나누어 떨어질 수 있습니다. 그때 산술만으로 의도를 재구성할 수 없습니다. 활성 오퍼/앤서 상태, 페이로드 타입, 패킷 시각은 계속 확보 가능해야 합니다.

RFC 3550은 순서와 타이밍을 위한 RTP 순서 번호와 타임스탬프 의미를 제공합니다.RFC 2327은 세션 기술 형식을,RFC 3264는 오퍼/앤서 모델을 제공합니다. 각 계층은 서로 다른 기록을 기여합니다. 순서 번호 공백은 모드 변경이 아닙니다. 성공한 SDP 교환은 발신자가 그것을 따랐다는 증명이 아닙니다. 깨끗한 프레임 수는 재생 근거가 아닙니다.

보안은 프레임링으로 수축하지 않았다

RFC 3952는 기밀성을 secure RTP 쪽으로 안내하고 악의적 페이로드로 인한 서비스 거부 노출을 논의합니다.RFC 3711은 SRTP 보호를 별도로 정의합니다. 이 분리는 운영상 중요합니다. 암호학적 수용은 보호된 바이트가 예상된 컨텍스트 아래 도착했음을 확립할 수 있지만, 잘못된 모드를 올바르게 만들 수는 없습니다. 반대로 완벽하게 나누어 떨어지는 보호되지 않은 페이로드는 어떤 신원도 증명하지 못합니다.

RFC Editor 메타데이터 페이지는 이 문서를 2004년 12월에 발표된 실험적(Experimental) 문서로 기록합니다. 그 교훈은 고정 크기 프레임링이 실수였다는 것이 아닙니다. 중복 필드를 제거하는 것은 종종 훌륭한 엔지니어링입니다. 교훈은 표현의 압축이 상태를 없애는 것이 아니라 상태를 옮긴다는 점입니다. RFC 3952는 사라진 개수를 세 부분으로 이루어진 증명에 두었습니다. 패킷 길이, 합의된 모드, 그리고 발신자의 준수입니다. 그중 하나만 남기는 운영은 나중에 수신기가 무엇을 믿었는지 설명할 수 없습니다.

출처