요약

  • RFC 3555는 타입, 서브타입, 클록 레이트, 채널 수, 패킷 시간 권고, 포맷별 매개변수가 각각 어디에 들어가야 하는지를 규정함으로써, 등록된 미디어 이름 하나가 MIME 방식 표현과 SDP 사이에서 이식 가능해지도록 했습니다.
  • 유효한 레지스트리 항목과 문법상 올바른 SDP 기술은, 엔드포인트가 해당 페이로드 포맷을 실제 구현했고, 세션 로컬 페이로드 번호 바인딩을 수용하며, 규격에 맞는 패킷을 수신하고, 쓸모 있는 미디어를 디코딩한다는 사실을 증명하지 않습니다.

RFC 3555에서 가장 많은 것을 말해주는 줄은 코덱 이름이 아니라 예시입니다.

audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15

이 한 줄을 RTP 패킷에 그대로 붙여 넣을 수는 없습니다. RTP 세션을 기술하기 위해 표준은 이를 여러 장소로 나누었습니다.audio는 SDPm=라인의 미디어 이름이 되었습니다.L16, 클록 레이트, 채널 수는a=rtpmap:97 L16/48000/2가 되었습니다. 포맷별 emphasis 설정은a=fmtp:97 emphasis=50-15로 갔습니다. 패킷 시간 권고는a=ptime:5가 되었습니다.

97이라는 번호는 미디어 타입 레지스트리에서 온 것이 아닙니다. 그 세션을 위해 선택된 동적 페이로드 타입이었습니다. 그 의미는 세션 기술이 97을 특정 클록과 채널 구성의 L16에 바인딩했기 때문에만 존재했습니다. 다른 세션은 97을 다른 용도로 쓸 수 있었고, 같은 L16 포맷에 다른 동적 번호를 쓸 수도 있었습니다. 재사용 가능한 정체성은 등록된 포맷 이름과 명세였고, 번호는 로컬 조율이었습니다.

이 분리가 바로 설계상 성과였습니다. 공통 이름은 MIME 방식 콘텐츠 기술에서 SDP로 건너갈 수 있었지만, 그 필드들이 하나의 덩어리로 옮겨지지는 않았습니다. 모든 필드에는 자신이 맡은 역할에 맞춘 목적지가 지정되어 있었습니다.

하나의 표현, 네 개의 목적지

RFC 3555는 최상위 타입을 SDP의 미디어 라인에, 서브타입을rtpmap에 배정했습니다.rate와channels는 RTP 타임스탬프 클록과 인코딩 매개변수를 결정하는 값이기 때문에 인코딩 이름 옆에 두었습니다.ptime과maxptime은 코덱 정체성이 아니라 패킷당 권장 또는 최대 미디어 길이를 기술하므로 독립적인 SDP 속성에 두었습니다. 코덱별 자료는 미디어 도구에 불투명한 포맷 매개변수를 전달하는 것이 목적인fmtp로 보냈습니다.

이것은 형식에 관한 사소한 규칙이 아니었습니다. 게이트웨이가ptime을 임의로 만든 코덱 문자열 안에 넣거나, 클록 레이트를 잘못된 위치에 복사하거나,fmtp를 스스로 설명되는 것으로 다룬다면, 두 시스템이 같은 서브타입을 표시하면서도 패킷에 대해서는 서로 다르게 이해할 수 있었습니다. 표준은 이 변환을 검사 가능하게 만들었습니다.

또한 권한 경계도 그렸습니다. 허용되는 페이로드 포맷별 매개변수 집합은 그 페이로드 포맷을 규정한 RFC에서 나옵니다. MIME 서브타입 등록은 그 매개변수들이fmtp에 어떻게 매핑되는지 문서화할 수 있지만, 페이로드 명세를 상응하게 개정하지 않고는 집합을 확장할 수 없습니다. 레지스트리는 실행 중인 와이어 의미론을 바꾸는 탈출구가 아니었습니다.

대소문자 통일은 겉보기보다 적은 일을 했다

RTP 프로파일 이름은 대문자로 인쇄되는 경우가 많았고, 미디어 서브타입은 흔히 소문자였습니다. 그래서 RFC 3555는 인코딩 이름을 두 위치 모두에서 대소문자를 구분하지 않도록 했습니다. 매개변수 이름도 미디어 타입 표현과 기본fmtp매핑에서 대소문자를 구분하지 않았습니다.

그러나 이 규칙이 모든 값을 서로 바꿔 쓸 수 있게 한 것은 아닙니다. 매개변수 값은 여전히 문법과 페이로드 포맷 명세가 지배합니다. 매개변수 이름을 소문자로 바꾼 것을 근거로 불투명한 값까지 소문자로 바꾸는 파서는, 표준이 지우지 않은 경계를 넘는 것입니다. 공통된 표기는 피상적인 불일치를 줄였을 뿐, 의미론적 타입 구분을 없애지는 못했습니다.

등록, 세션 바인딩, 실행

등록 절차는 RTP 타임스탬프 클록 레이트(들)를 포함한 공개된 페이로드 포맷 명세를 요구했습니다. 타입을 RTP에서, 그리고 가능한 경우 다른 전송 방식에서도 사용할 수 있게 했지만, 어떤 매개변수가 어떤 모드에 적용되는지 등록이 명시하도록 요구했습니다. 2003년에도 이미 그 이름은 모든 전송 방식이 동일한 프레이밍을 쓴다는 보편적 약속이 아니었습니다.

이후의 수리도 시사적입니다. RFC 4855와 RFC 4856은 RFC 3555를 폐기했습니다. RFC 4855는 매핑 절차를 유지하면서 개정된 미디어 타입 규칙에 맞게 갱신하고, RTP 전송과 비-RTP 파일 전송이 서브타입을 공유할 수 있는 시점을 더 명시적으로 밝혔습니다. 데이터 포맷은 명시된 검사 기준에서 동등해야 했고, 필수 매개변수 집합도 일치해야 했습니다. 그렇지 않으면 별개의 타입이 요구되었습니다. RFC 4856은 구체적인 RTP 프로파일 등록들을 추출하면서, 이 추출이 그 등록들에 기술적 변경을 가져오지 않는다고 밝혔습니다.

표준이 나뉜 이유는 절차, 등록 기록, 페이로드 명세가 서로 다른 유지보수 수명을 가지기 때문입니다. 현재 IANA 스냅샷에도audio/L16,audio/PCMA,audio/PCMU같은 이름이 RFC 4856을 가리키고 있습니다. 2026-10-06에 동결된 XML에서 오디오 레지스트리에는 165건, 비디오 레지스트리에는 97건의 기록이 있고, 20건이 RFC 4856을 직접 인용합니다. 이 수치는 그 날짜의 레지스트리를 기술할 뿐이며, 특정 장치에 설치된 코덱에 대해서는 아무것도 말하지 않습니다.

동결된 소스 패킷에 담긴 오늘날의 SDP 명세인 RFC 8866은 이 구조를 그대로 보존합니다.rtpmap은 페이로드 타입 번호를 인코딩 이름, 클록 레이트, 인코딩 매개변수에 바인딩합니다.fmtp는 SDP가 이해할 것을 요구하지 않고 포맷별 매개변수를 전달합니다. 따라서 현재 파서는 매핑 규율을 재현하면서도 이후 단계에서 실패할 수 있습니다. 엔드포인트가 코덱을 구현하지 않았을 수도, 매개변수 조합을 거부할 수도, 형식이 잘못된 패킷을 받을 수도 있으며, 어떤 애플리케이션도 쓸 수 없는 오디오를 디코딩할 수도 있습니다.

근거의 사다리가 중요합니다. 먼저 파서가 미디어 타입 문자열을 수용했는지 묻습니다. 그다음 서브타입이 등록되어 있고 의도한 전송 방식에 허용되는지 묻습니다. 그다음 모든 매개변수가 올바른 SDP 필드에 도달했는지 확인합니다. 그다음 세션 로컬 페이로드 번호 바인딩을 확인합니다. 그 뒤에야 엔드포인트 능력, 패킷 규격 준수, 디코딩, 애플리케이션 결과가 옵니다.

RFC 3555의 역사적 교훈은 이름이 상호운용성을 해결한다는 것이 아닙니다. 이름은 모든 맥락 전환에 명시적이고 검토 가능한 지도가 있을 때—그리고 레지스트리가 최종적으로 그것을 실행해야 하는 구현체를 가장하지 않을 때—비로소 상호운용 가능해진다는 것입니다.

출처