요약

  • RFC 5577은 기존 RTP 페이로드 규격을 대체하여 G.722.1 부속서 C의 14 kHz 오디오, 32 kHz 샘플링 클록 및 48 kbit/s 모드를 지원했습니다.
  • 깔끔한 단절을 강제하지는 않았습니다. 이 RFC는 하위 호환성을 위해 이전 16 kHz 프로파일을 함께 제안할 것을 권고하면서, 사용하려는 각 클록 레이트·비트레이트 구성은 SDP를 통해 선언하도록 요구합니다.

후속 규격은 이전 규격의 피어를 지우지 않았다

2009년 7월 RFC 5577이 나올 때 머리말에는 “Obsoletes: 3047”이라고 적혀 있었습니다. 이 문구는 스위치가 켜진 것처럼 들릴 수 있습니다. 하나의 규격이 빠지고 다음 것이 들어온다. 그러나 문서의 상호운용성 절은 더 실용적인 이야기를 들려줍니다. RFC 3047은 16 kHz 샘플링 클록을 갖는 G.722.1을 기술했습니다. 이후 개정판은 개정된 ITU-T 권고안 부속서 C에서 정의된 초광대역(superwideband) 오디오에 대한 지원을 추가하여, 오디오 대역폭을 14 kHz로 확장하고 32 kHz 클록 구성과 48 kbit/s 레이트를 더했습니다.

이들은 서로 다른 측정값입니다. 14 kHz 수치는 인코딩된 오디오 대역폭을, 16 또는 32 kHz는 RTP 타임스탬프에 쓰이는 샘플링 클록을, 24·32·48 kbit/s는 코덱의 인코딩 레이트를 나타냅니다. RFC 5577은 이 차원들을 하나의 “품질” 설정으로 묶지 않았습니다. 세션 신호에 사용 가능한 조합을 명명할 방법을 제공했습니다.

코덱 비트스트림에는 비트레이트가 바뀔 때 대역 내 알림이 없었습니다. 따라서 RFC 5577은 별도의 신호 방식을 요구하고 각 RTP 페이로드 타입에 대해 비트레이트를 일정하게 유지했습니다. 애플리케이션은 패킷마다 프로파일을 바꿀 수 있었지만, 서로 다른 페이로드 타입 값을 할당하는 경우에만 가능했습니다. SDP에서a=rtpmap행은 인코딩과 클록 레이트를 식별하고,a=fmtp가 비트레이트를 제공합니다. 이 조합이 수신 측에 이해하도록 요청되는 구성을 기술합니다.

Offer/Answer 규칙은 이 선언에 실질적 결과를 부여했습니다. RFC 5577은 제안자가 사용하려는 모든 구성은 선언되어야 한다고 규정합니다. 그리고 호환성 격차를 직접 짚습니다. 이전 RFC는 16 kHz 클록만 지원했으므로, 상호운용성을 원하는 시스템은 16 kHz 페이로드 타입도 함께 제안해야 합니다. 예시 제안에는 16 kHz/24 kbit/s 옵션과 32 kHz/48 kbit/s 옵션이 별도의 페이로드 타입으로 나열되어 있습니다.

이것이 모든 구형 단말이 성공적으로 협상할 수 있다는 뜻도, 새 프로파일이 자동으로 폴백된다는 뜻도 아닙니다. 제안은 지원되는 선택지에 대한 진술이지, 응답이나 오디오가 청취자에게 도달했다는 증거가 아닙니다. 수신 단말은 여전히 자신이 지원하는 구성을 선택해야 하고, 세션은 합의된 프로파일을 운반해야 합니다. RFC 5577은 경로를 보존했을 뿐, 누가 그 경로를 사용했는지는 증명하지 않았습니다.

패킷 형식은 또 하나의 경계를 그대로 유지했습니다. 프레임은 20밀리초 길이를 유지했습니다. 표준 레이트에서 각 프레임은 60, 80 또는 120 옥텟을 차지했습니다. 패킷은 연속 프레임을 집합할 수 있었지만, 프레임들은 비트레이트와 클록 레이트를 공유해야 했고, 하나의 프레임이 패킷 경계에 걸칠 수는 없었습니다. 프레임 수는 별도의 페이로드 헤더로 알려지지 않고 페이로드 길이와 프레임당 예상 크기로부터 추론되었습니다. RFC 5577은 지연이 중요한 곳에서는 더 적은 프레임을, 스트리밍이나 메시징이 허용하는 곳에서는 더 많은 프레임을 권고했습니다. 보편적인 지연 수치는 정하지 않았습니다.

이전 문서로 읽으면, RFC 5577은 “새 코덱이 옛 코덱을 대체”라기보다 선택을 읽을 수 있게 유지하는 데 가깝습니다.Obsoletes행은 규격 자체를 대체했습니다. 16 kHz 제안은 이전 호환성 경계를 계속 보이게 했습니다. 어느 진술도, 그 자체로는 어느 쪽을 얼마나 많은 단말이 구현했는지 말해주지 않습니다.

출처