RFC 5219: 세션 이름 바로잡기

요약

RFC 3119의 SDP 지시문은mp3라고 말했지만, 등록된 미디어 서브타입과 인접한rtpmap예시는mpa-robust라고 말했다. RFC 5219는 인코딩 이름을 일관되게 만들었다.
후속 문서는 ADU 기반 RTP 페이로드 설계를 유지하고 의사코드 수정을 사실상 규범적이지 않은 경미한 명확화로 기술했다. 표준 기록은 배포된 소프트웨어가 불일치 라벨을 사용했는지, 세션이 실패했는지 여부를 보여주지 않는다.

기술 문서에는 한 이름, 예시에는 다른 이름

이 모순은 대충 읽으면 놓치기 쉬울 만큼 작다. 2001년에 발행된 RFC 3119는 자신의 MP3 페이로드 형식에 대해mpa-robust를 미디어 서브타입으로 등록했다. 그런데 SDP 절에서는 인코딩 이름이mp3여야 한다고(SHAL) 규정한다. 바로 아래의 예시는 동적 페이로드 타입 121을 지정하면서a=rtpmap:121 mpa-robust/90000이라고 적는다.

이 줄들은 서로 다른 표면에서 같은 형식을 기술한다. RTP는 번호가 매겨진 페이로드 타입을 운반하며, 동적 번호에 대해서는 SDPrtpmap속성이 그 번호가 어떤 인코딩과 클록 레이트를 뜻하는지 상대 엔드포인트에 알려준다. 이 매핑은 RFC 4566이 정의한다. 따라서 RFC 3119는 미디어 서브타입과 작성된 매핑이 서로 일치하는 데도, 세션 수준 기술자에 대해서는 호환되지 않는 두 개의 이름을 독자에게 제시했다.

이 구분은 짧은 문자열이 암시하는 것보다 중요하다. 페이로드 타입 번호는 스스로를 설명하지 않는다. 엔드포인트들은 RTP 패킷 속 번호와 수신자가 기대하는 인코딩 사이의 공유된 매핑이 필요하다. 하나의 형식은 일관된 패킷 레이아웃을 갖추면서도 설정 경계에서는 일관되지 않게 기술될 수 있다. 이 문서는 사양 결함을 입증한다. 실제 어떤 엔드포인트가 이를 어떻게 다뤘는지는 보여주지 않는다.

이 페이로드 형식이 존재했던 이유

원래 설계는 MP3 레이어 III의 특정한 성질을 다루었다. MP3 프레임은 앞선 프레임들이 운반한 인코딩된 데이터 안을 역방향으로 가리킬 수 있으므로, 하나의 프레임이 항상 독립적인 디코딩 단위는 아니다. RFC 3119는 통상적인 프레임 정렬 RTP 패킷은 패킷 하나의 손실이 온전히 도착한 다른 프레임들의 데이터 유용성까지 해칠 수 있다고 주장했다.

그 대안은 스트림을 ADU(Application Data Unit)로 재배치했다. 각 ADU 앞에는 자신의 크기와 데이터가 다른 패킷에서 이어지는지 여부를 밝히는 디스크립터가 붙었다. 송신자는 ADU를 인터리브하여 연속하는 단위들이 연속하지 않은 패킷으로 이동하게 할 수도 있었다. 이 제안은 단순한 "중복 추가"가 아니었다. 인코딩된 정보를 보존하면서 패킷 경계가 디코더의 데이터 단위에 상대적으로 어디에 놓이는지를 바꾼 것이다.

2008년 2월에 발행된 RFC 5219는 이 기본 접근을 다시 출판한다. 서문은 뒤로 가리키기(back-pointer) 문제, ADU, 디스크립터, 선택적 인터리빙을 다시 설명한다. 후속 문서의 초록은 SDP 절과 의사코드 부록의 오타를 바로잡기 위해 RFC 3119를 폐기(obsolete)한다고 말한다. 부록 C는 더 정확하다. SDP 인코딩 이름을 바로잡는 것이 주요 변경이며, 부록 A와 B는 규범적이지 않은 의사코드에 대한 경미한 수정과 명확화를 받았다.

바로잡음은 명시적이다. RFC 5219는 SDP 인코딩 이름이 등록된 미디어 서브타입과 일치하도록mpa-robust여야 한다고(SHAL) 규정하며, 예시는 동적 페이로드 타입 121을mpa-robust/90000에 매핑한다. RFC 3119에 대해 RFC Editor가 검증한 정오표(erratum) 역시 근본적인 불일치와 몇 가지 코드 예시 수정을 기록한다. 뒤로 가리키기는 값이지 크기가 아니며, 한 변수는curADU가 아니라prevADU여야 하고, 두 개의 디인터리빙 경계는 32가 아니라 256이어야 한다는 것 등이다. 이것들은 적힌 절차를 명확히 한다. 2008년 이후 배포된 페이로드가 바뀌었다는 증거가 아니다.

개정 번호는 사고 보고서가 아니다

RFC 5219는 표준이 두 개 이상의 층위에서 어떻게 수리될 수 있는지를 보여주는 유용한 기록이다. SDP 이름은 규범적인 세션 기술 지침이다. 거기서의 바로잡음은 사양이 참여자들에게 인코딩을 무엇이라 부르라고 말하는지를 바꾼다. 부록 편집은 RFC 5219 자체가 비규범적이라고 명시한 샘플 의사코드에 관한 것이다. 어느 하나만으로도 운영상 문제의 규모를 확립하지는 못한다.

이 문서들에는 구현 조사, 패킷 추적, 실패한 통화, 벤더 릴리스 노트, 전후 비교 테스트가 없다. 어느 엔드포인트가 실제로mp3를 광고했는지, 다른 엔드포인트가 이를 거부했는지, 철자를 바로잡는 것이 측정된 배포 환경에서 상호운용성을 개선是否했는지도 말하지 않는다. RFC Editor가 수리한 정오표조차 기록 속 결함을 증명할 뿐, 소프트웨어가 그 결함을 얼마나 자주 재현했는지는 증명하지 않는다.

그것이 지켜야 할 역사적 경계다. RFC 5219는 세션 기술 지침의 바로잡음과 일부 구현 지침의 수리가 필요했기 때문에 기존 문서를 대체했다. ADU 페이로드 모델은 유지했다. 이 출판물은 표준 저자들이 무엇을 바로잡았는지를 알려준다. 그 바로잡음이 실제 시스템에서 의미가 있었는지에 대한 답을 내려면 구현과 세션에서 나오는 별도의 증거가 필요하다.