프론트엔드 WebRTC 미디어 협상: 코덱 선택 알고리즘 해독

실시간 통신(RTC)의 역동적인 세계에서 WebRTC는 피어 투 피어 오디오, 비디오 및 데이터 채널을 웹 브라우저 내에서 직접 가능하게 하는 중요한 기술입니다. 이러한 연결을 설정하는 데 있어 중요하지만 종종 복잡한 측면은 미디어 협상 프로세스, 특히 코덱 선택의 복잡한 상호 작용입니다. 이 프로세스는 WebRTC 통화의 양측이 교환되는 미디어 스트림을 이해하고 렌더링할 수 있도록 합니다. 프론트엔드 개발자에게 이 알고리즘에 대한 깊은 이해는 강력하고 고품질이며 보편적으로 호환되는 RTC 애플리케이션을 구축하는 데 필수적입니다.

기반: 세션 설명 프로토콜 (SDP)

WebRTC 미디어 협상의 핵심에는 세션 설명 프로토콜 (SDP)이 있습니다. SDP는 멀티미디어 세션을 설명하는 데 사용되는 텍스트 기반 형식입니다. 미디어 자체를 전송하는 것이 아니라 세션의 기능 및 매개변수를 전달하는 데 사용됩니다. 두 피어가 WebRTC 연결을 시작하면 SDP 제안 및 응답을 교환합니다. 이 교환은 다음을 자세히 설명합니다.

• 전송되는 미디어 유형 (오디오, 비디오, 데이터).
• 각 미디어 유형에 대해 지원되는 코덱.
• 미디어 송수신을 위한 네트워크 주소 및 포트.
• 암호화, 대역폭 등 기타 세션별 매개변수.

코덱 선택 알고리즘은 이 SDP 교환 내에서 작동합니다. 각 피어는 지원하는 코덱을 광고하고 일련의 협상을 통해 둘 다 활용할 수 있는 공통 코덱 세트에 도달합니다. 다양한 브라우저, 운영 체제 및 하드웨어가 다양한 효율성과 품질 수준으로 다른 코덱을 지원할 수 있기 때문에 이것이 복잡성이 발생하는 부분입니다.

WebRTC의 코덱 이해

선택 알고리즘에 대해 자세히 알아보기 전에 코덱이 무엇이며 왜 중요한지 간략하게 정의해 보겠습니다.

• 코덱 (코더-디코더): 코덱은 데이터를 압축 및 압축 해제하는 장치 또는 프로그램입니다. WebRTC에서 코덱은 원시 오디오 및 비디오 데이터를 네트워크를 통해 전송하기에 적합한 형식으로 인코딩(압축)하고 수신 측에서 재생 가능한 형식으로 압축된 데이터를 디코딩(압축 해제)하는 역할을 합니다.
• 목적: 주요 목적은 미디어 스트림 전송에 필요한 대역폭을 줄여 제한된 용량의 네트워크에서도 실시간 통신을 가능하게 하는 것입니다. 또한 다른 장치 및 플랫폼 간의 호환성을 보장하는 데 중요한 역할을 합니다.

WebRTC는 일반적으로 다양한 오디오 및 비디오 코덱을 지원합니다. 가장 일반적인 코덱은 다음과 같습니다.

오디오 코덱:

• Opus: WebRTC 오디오의 사실상 표준입니다. 음성과 음악 모두에 대해 설계된 다용도, 오픈 소스 및 로열티 프리 코덱으로, 광범위한 네트워크 조건 및 비트 전송률에서 우수한 품질을 제공합니다. 모든 WebRTC 애플리케이션에 강력히 권장됩니다.
• G.711 (PCMU/PCMA): 구형이며 널리 호환되는 코덱이지만 일반적으로 Opus보다 효율성이 떨어집니다. PCMU(μ-law)는 북미 및 일본에서 흔히 사용되며, PCMA(A-law)는 유럽 및 기타 지역에서 사용됩니다.
• iSAC: Google에서 개발한 또 다른 광대역 오디오 코덱으로, 다양한 네트워크 조건에 적응하는 능력으로 알려져 있습니다.
• ILBC: 저대역폭을 위해 설계된 구형 협대역 코덱입니다.

비디오 코덱:

• VP8: Google에서 개발한 오픈 소스, 로열티 프리 비디오 코덱입니다. 널리 지원되며 좋은 성능을 제공합니다.
• VP9: VP8의 후속 제품으로, 유사한 비트 전송률에서 향상된 압축 효율성과 더 높은 품질을 제공합니다. 또한 Google의 오픈 소스 및 로열티 프리 코덱입니다.
• H.264 (AVC): 매우 효율적이고 널리 채택된 독점 비디오 코덱입니다. 매우 일반적이지만 라이선스가 일부 애플리케이션에 대한 고려 사항이 될 수 있지만 대부분의 브라우저는 WebRTC용으로 이를 제공합니다.
• H.265 (HEVC): H.264보다 훨씬 효율적인 후속 제품이지만 라이선스가 더 복잡합니다. WebRTC에서 HEVC 지원은 H.264보다 덜 보편적입니다.

실행 중인 코덱 선택 알고리즘

코덱 선택 프로세스는 주로 SDP 제안/응답 모델에 의해 주도됩니다. 작동 방식에 대한 간소화된 분석은 다음과 같습니다.

1단계: 제안

WebRTC 피어(피어 A라고 가정)가 통화를 시작하면 SDP 제안을 생성합니다. 이 제안에는 지원하는 모든 오디오 및 비디오 코덱과 관련 매개변수 및 기본 순서가 포함됩니다. 제안은 신호 서버를 통해 다른 피어(피어 B)로 전송됩니다.

SDP 제안은 일반적으로 다음과 같은 모습입니다 (간소화된 스니펫):

v=0
...
a=rtpmap:102 opus/48000/2
a=rtpmap:103 VP8/90000
a=rtpmap:104 H264/90000
...

이 스니펫에서:

• a=rtpmap 줄은 코덱을 설명합니다.
• 숫자 (예: 102, 103)는 세션 내에서 코덱의 로컬 식별자인 페이로드 유형입니다.
• opus/48000/2는 샘플 속도 48000Hz 및 2 채널(스테레오)인 Opus 코덱을 나타냅니다.
• VP8/90000 및 H264/90000는 일반적인 비디오 코덱입니다.

2단계: 응답

피어 B는 SDP 제안을 받습니다. 그런 다음 피어 A의 지원 코덱 목록을 검토하고 자체 지원 코덱 목록과 비교합니다. 목표는 두 피어 모두 처리할 수 있는 가장 높은 공통 코덱을 찾는 것입니다.

일반적으로 공통 코덱을 선택하는 알고리즘은 다음과 같습니다.

1. 피어 A의 광고된 코덱을 반복합니다. 일반적으로 제안에 표시된 순서대로 (종종 피어 A의 기본 설정을 반영함).
2. 피어 A 목록의 각 코덱에 대해 피어 B도 해당 코덱을 지원하는지 확인합니다.
3. 일치하는 항목을 찾은 경우: 이 코덱은 해당 미디어 유형(오디오 또는 비디오)에 대해 선택된 코덱이 됩니다. 피어 B는 이 선택된 코덱과 해당 매개변수를 포함하는 SDP 응답을 생성하고 페이로드 유형을 할당합니다. 응답은 신호 서버를 통해 피어 A로 다시 전송됩니다.
4. 모든 코덱을 확인한 후 일치하는 항목을 찾을 수 없는 경우: 이는 해당 미디어 유형에 대한 공통 코덱 협상 실패를 의미합니다. 이 경우 피어 B는 해당 미디어 유형을 응답에서 생략하거나 (통화에 대해 오디오 또는 비디오를 효과적으로 비활성화) 대체 협상을 시도할 수 있습니다.

피어 B의 SDP 응답은 합의된 코덱을 포함합니다.

v=0
...
m=audio 9 UDP/TLS/RTP/SAVPF 102
...
a=rtpmap:102 opus/48000/2
...
m=video 9 UDP/TLS/RTP/SAVPF 103
...
a=rtpmap:103 VP8/90000
...

응답은 이제 피어 B가 합의된 코덱에 사용할 페이로드 유형(예: Opus의 경우 102, VP8의 경우 103)을 지정했음을 알 수 있습니다.

3단계: 연결 설정

두 피어가 SDP 제안 및 응답을 교환하고 공통 코덱에 동의하면 미디어 교환을 시작하기 위한 필수 매개변수를 설정한 것입니다. 그런 다음 WebRTC 스택은 이 정보를 사용하여 미디어 전송(UDP를 통한 RTP)을 구성하고 피어 투 피어 연결을 설정합니다.

코덱 선택에 영향을 미치는 요인

기본 알고리즘은 간단하지만 (첫 번째 공통 코덱 찾기), 실제 구현 및 선택된 코덱은 여러 요인의 영향을 받습니다.

1. 브라우저 구현 및 기본값

다양한 브라우저(Chrome, Firefox, Safari, Edge)는 WebRTC의 자체 내부 구현과 자체 기본 코덱 기본 설정을 가지고 있습니다. 예를 들면 다음과 같습니다.

• Chrome/Chromium 기반 브라우저는 일반적으로 VP8 및 Opus를 우선합니다.
• Firefox도 Opus 및 VP8를 선호하지만 플랫폼에 따라 H.264에 대해 다른 기본 설정을 가질 수 있습니다.
• Safari는 역사적으로 H.264 및 Opus에 대한 강력한 지원을 제공했습니다.

이는 브라우저가 SDP 제안에 지원되는 코덱을 나열하는 순서가 협상 결과에 상당한 영향을 미칠 수 있음을 의미합니다. 일반적으로 브라우저는 기본 설정, 가장 효율적인 또는 가장 일반적으로 지원되는 코덱을 먼저 나열합니다.

2. 운영 체제 및 하드웨어 기능

기본 운영 체제 및 하드웨어도 코덱 지원에 영향을 미칠 수 있습니다. 예를 들면 다음과 같습니다.

• 일부 시스템은 특정 코덱(예: H.264)에 대해 하드웨어 가속 인코딩/디코딩을 가질 수 있어 사용하기에 더 효율적입니다.
• 모바일 장치는 데스크톱 컴퓨터와 다른 코덱 지원 프로필을 가질 수 있습니다.

3. 네트워크 조건

SDP 초기 협상의 직접적인 부분은 아니지만, 네트워크 조건은 선택된 코덱의 성능에 중요한 역할을 합니다. WebRTC에는 대역폭 추정(BE) 및 적응을 위한 메커니즘이 포함되어 있습니다. 코덱이 선택된 후:

• 적응 비트 전송률: Opus 및 VP9와 같은 최신 코덱은 사용 가능한 네트워크 대역폭에 따라 비트 전송률 및 품질을 조정하도록 설계되었습니다.
• 패킷 손실 은닉 (PLC): 패킷이 손실되면 코덱은 품질 저하를 최소화하기 위해 누락된 데이터를 추측하거나 재구성하는 기술을 사용합니다.
• 코덱 전환 (덜 일반적): 일부 고급 시나리오에서는 애플리케이션이 네트워크 조건이 크게 변경되면 동적으로 코덱을 전환하려고 시도할 수 있지만, 이는 복잡한 작업입니다.

초기 협상은 호환성을 목표로 하며, 지속적인 통신은 선택된 코덱의 적응적 특성을 활용합니다.

4. 애플리케이션별 요구 사항

개발자는 JavaScript API를 통해 SDP 제안/응답을 조작하여 코덱 선택에 영향을 줄 수 있습니다. 이것은 고급 기술이지만 다음을 허용합니다.

• 특정 코덱 강제 적용: 애플리케이션에 특정 코덱에 대한 엄격한 요구 사항이 있는 경우(예: 레거시 시스템과의 상호 운용성을 위해), 해당 코덱을 강제로 선택하도록 시도할 수 있습니다.
• 코덱 우선순위 지정: SDP 제안 또는 응답에서 코덱 순서를 변경하여 애플리케이션이 기본 설정을 신호할 수 있습니다.
• 코덱 비활성화: 코덱이 문제가 있는 것으로 알려졌거나 필요하지 않은 경우 명시적으로 제외할 수 있습니다.

프로그래밍 방식 제어 및 SDP 조작

브라우저는 SDP 협상의 많은 부분을 자동으로 처리하지만, 프론트엔드 개발자는 WebRTC JavaScript API를 사용하여 더 세밀한 제어를 얻을 수 있습니다.

1. `RTCPeerConnection.createOffer()` 및 `createAnswer()`

이 메서드는 SDP 제안 및 응답 객체를 생성합니다. `setLocalDescription()`을 사용하여 `RTCPeerConnection`에 이러한 설명을 설정하기 전에 SDP 문자열을 수정할 수 있습니다.

2. `RTCPeerConnection.setLocalDescription()` 및 `setRemoteDescription()`

이 메서드는 각각 로컬 및 원격 설명을 설정하는 데 사용됩니다. `setLocalDescription` (제안자) 및 `setRemoteDescription` (응답자)이 모두 성공적으로 호출되면 협상이 발생합니다.

3. `RTCSessionDescriptionInit`

`RTCSessionDescriptionInit`의 `sdp` 속성은 SDP를 포함하는 문자열입니다. 이 문자열을 구문 분석하고 수정한 다음 다시 조립할 수 있습니다.

예: VP8보다 VP9 우선순위 지정

VP9가 VP8보다 우선순위가 높도록 하려면 어떻게 해야 할까요? 브라우저의 기본 SDP 제안은 다음과 같은 순서로 나열될 수 있습니다.

a=rtpmap:103 VP8/90000
a=rtpmap:104 VP9/90000

SDP 제안을 가로채서 VP9의 우선순위를 지정하기 위해 줄을 바꾸면 다음과 같이 할 수 있습니다.

let offer = await peerConnection.createOffer();

// SDP 문자열 수정
let sdpLines = offer.sdp.split('\n');
let vp8LineIndex = -1;
let vp9LineIndex = -1;

for (let i = 0; i < sdpLines.length; i++) {
    if (sdpLines[i].startsWith('a=rtpmap:') && sdpLines[i].includes('VP8/90000')) {
        vp8LineIndex = i;
    }
    if (sdpLines[i].startsWith('a=rtpmap:') && sdpLines[i].includes('VP9/90000')) {
        vp9LineIndex = i;
    }
}

if (vp8LineIndex !== -1 && vp9LineIndex !== -1) {
    // VP9가 VP8 뒤에 나열된 경우 VP8 및 VP9 줄 교환
    if (vp9LineIndex > vp8LineIndex) {
        [sdpLines[vp8LineIndex], sdpLines[vp9LineIndex]] = [sdpLines[vp9LineIndex], sdpLines[vp8LineIndex]];
    }
}

offer.sdp = sdpLines.join('\n');

await peerConnection.setLocalDescription(offer);
// ... 제안을 원격 피어로 전송 ...

주의: 직접 SDP 조작은 불안정할 수 있습니다. 브라우저 업데이트로 인해 SDP 형식이 변경될 수 있으며 잘못된 수정은 협상을 중단시킬 수 있습니다. 이 접근 방식은 일반적으로 고급 사용 사례 또는 특정 상호 운용성이 필요한 경우에 예약됩니다.

4. `RTCRtpTransceiver` API (최신 접근 방식)

코덱 선택에 영향을 미치는 더 강력하고 권장되는 방법은 `RTCRtpTransceiver` API를 사용하는 것입니다. 미디어 트랙을 추가할 때(예: `peerConnection.addTrack(stream.getAudioTracks()[0], 'audio')`), 트랜시시버가 생성됩니다. 그런 다음 트랜시시버를 가져와 direction 및 기본 코덱을 설정할 수 있습니다.

트랜시시버에 대한 지원 코덱을 가져올 수 있습니다.

const transceivers = peerConnection.getTransceivers();
transceivers.forEach(transceiver => {
    if (transceiver.kind === 'audio') {
        const codecs = transceiver.rtpSender.getCapabilities().codecs;
        console.log('지원되는 오디오 코덱:', codecs);
    }
});

모든 브라우저에서 보편적으로 트랜시시버에 직접 `setPreferredCodec` 메서드가 있는 것은 아니지만, WebRTC 사양은 브라우저가 SDP에 표시된 코덱 순서를 존중하도록 하여 상호 운용성을 목표로 합니다. 더 직접적인 제어는 종종 `createOffer`/`createAnswer`를 통해 SDP 제안/응답 생성을 조작하고 설명을 설정하기 전에 코덱을 필터링/재정렬하여 얻습니다.

5. `RTCPeerConnection` 제약 조건 ( `getUserMedia`용)

`navigator.mediaDevices.getUserMedia()`를 사용하여 미디어 스트림을 얻을 때 요청되는 미디어의 품질 또는 유형에 영향을 미치는 제약 조건을 지정할 수 있습니다. 그러나 이러한 제약 조건은 주로 피어 간의 코덱 협상이 아닌 미디어 캡처 자체에 영향을 미칩니다.

글로벌 애플리케이션을 위한 과제 및 모범 사례

글로벌 WebRTC 애플리케이션을 구축하는 것은 미디어 협상과 관련된 고유한 과제를 제시합니다.

1. 글로벌 브라우저 및 장치 파편화

전 세계적으로 다양한 장치, 운영 체제 및 브라우저 버전이 사용됩니다. WebRTC 애플리케이션이 이 파편화 전반에 걸쳐 원활하게 작동하도록 보장하는 것은 주요 장애물입니다.

• 예: 구형 Android 장치를 사용하는 남미 사용자는 최신 iOS 장치를 사용하는 동아시아 사용자와 다른 H.264 프로필 또는 코덱 지원을 가질 수 있습니다.

2. 네트워크 가변성

인터넷 인프라는 전 세계적으로 크게 다릅니다. 지연 시간, 패킷 손실 및 사용 가능한 대역폭은 극적으로 다를 수 있습니다.

• 예: 서유럽의 고속 광섬유 네트워크에 있는 두 사용자 간의 통화는 동남아시아의 농촌 지역에 있는 모바일 네트워크에 있는 사용자 간의 통화와 매우 다른 경험을 제공합니다.

3. 레거시 시스템과의 상호 운용성

많은 조직이 최신 WebRTC 코덱 또는 프로토콜을 완전히 지원하지 않는 기존 화상 회의 하드웨어 또는 소프트웨어에 의존합니다. 이 격차를 해소하려면 G.711 또는 H.264와 같이 덜 효율적이지만 더 일반적인 코덱에 대한 지원을 구현해야 하는 경우가 많습니다.

모범 사례:

• 오디오의 경우 Opus 우선: Opus는 WebRTC에서 가장 다용도로 사용되고 널리 지원되는 오디오 코덱입니다. 다양한 네트워크 조건에서 탁월한 성능을 제공하며 모든 애플리케이션에 강력히 권장됩니다. SDP 제안에서 눈에 띄게 나열되도록 하십시오.
• 비디오의 경우 VP8/VP9 우선: VP8 및 VP9는 오픈 소스이며 널리 지원됩니다. H.264도 일반적이지만 VP8/VP9는 라이선스 문제 없이 좋은 호환성을 제공합니다. 대상 플랫폼 전반에 걸쳐 지원이 일관되면 더 나은 압축 효율성을 위해 VP9를 고려하십시오.
• 강력한 신호 서버 사용: 안정적인 신호 서버는 다양한 지역에 걸쳐 SDP 제안 및 응답을 효율적이고 안전하게 교환하는 데 필수적입니다.
• 다양한 네트워크 및 장치에서 광범위하게 테스트: 실제 네트워크 조건을 시뮬레이션하고 글로벌 사용자 기반을 대표하는 다양한 장치 및 브라우저에서 애플리케이션을 테스트하십시오.
• WebRTC 통계 모니터링: `RTCPeerConnection.getStats()` API를 활용하여 코덱 사용량, 패킷 손실, 지터 및 기타 지표를 모니터링하십시오. 이 데이터는 다양한 지역에서 성능 병목 현상 및 코덱 관련 문제를 식별하는 데 매우 중요합니다.
• 대체 전략 구현: 최선을 다하는 동시에 특정 코덱에 대한 협상이 실패하는 시나리오에 대비하십시오. 우아한 대체 메커니즘을 마련하십시오.
• 복잡한 시나리오의 경우 서버 측 처리(SFU/MCU) 고려: 많은 참가자가 있거나 녹화 또는 트랜스코딩과 같은 고급 기능이 필요한 애플리케이션의 경우 선택적 전달 단위(SFU) 또는 다점 제어 장치(MCU)를 사용하면 처리를 오프로드하고 클라이언트 측 협상을 단순화할 수 있습니다. 그러나 이는 서버 인프라 비용을 추가합니다.
• 브라우저 표준 최신 정보 유지: WebRTC는 끊임없이 발전하고 있습니다. 새로운 코덱 지원, 표준 변경 및 브라우저별 동작을 파악하십시오.

결론

WebRTC 미디어 협상 및 코덱 선택 알고리즘은 복잡해 보이지만 기본적으로 두 피어 간의 공통점을 찾는 것에 관한 것입니다. SDP 제안/응답 모델을 활용하여 WebRTC는 공유 오디오 및 비디오 코덱을 식별하여 호환 가능한 통신 채널을 설정하려고 합니다. 글로벌 애플리케이션을 구축하는 프론트엔드 개발자에게 이 프로세스를 이해하는 것은 단순히 코드를 작성하는 것을 넘어 보편성을 위한 디자인입니다.

Opus 및 VP8/VP9와 같이 강력하고 널리 지원되는 코덱을 우선시하고 다양한 글로벌 환경에서 철저한 테스트를 수행하는 것은 원활하고 고품질의 실시간 통신의 기반을 마련할 것입니다. 코덱 협상의 뉘앙스를 마스터함으로써 WebRTC의 잠재력을 최대한 발휘하고 전 세계 사용자에게 탁월한 사용자 경험을 제공할 수 있습니다.