RTP와 음성 코덱: G.711·Opus, 전화 음성이 AI 모델로 흘러가는 방식

RTP(Real-time Transport Protocol)는 통화 음성을 작은 패킷으로 나누어 실시간으로 전달하는 프로토콜이고, 음성 코덱은 그 패킷에 담을 소리를 압축하고 복원하는 방식입니다. 전화망 음성은 8kHz로 샘플링하는 G.711이 기본이고, 인터넷 음성 서비스에서는 네트워크 상황에 맞춰 품질을 조절하는 Opus가 많이 쓰입니다. 전화 음성이 AI 모델에 닿으려면 RTP 패킷을 디코딩해 모델이 받는 형식으로 바꾸는 과정이 필요합니다.

RTP: 통화 음성을 실어 나르는 패킷

RTP는 RFC 3550에 정의된 프로토콜로, 보통 UDP 위에서 동작합니다. 음성은 잃어버린 패킷을 다시 받기 위해 기다리는 것보다 조금 잃더라도 제때 도착하는 것이 중요하기 때문에 TCP 대신 UDP를 씁니다. RTP 헤더는 기본 12바이트이며 다음 정보를 담습니다.

RTP와 짝을 이루는 RTCP(RTP Control Protocol)는 패킷 손실률, 지터, 왕복 지연 계산에 쓰는 수신 품질 보고를 주고받는 제어 채널입니다. 전통적으로 RTP 포트 바로 다음 홀수 포트를 쓰며, 하나의 포트로 함께 보내는 rtcp-mux(RFC 5761)도 쓰입니다. 어떤 주소와 포트로 RTP를 보낼지는 SIP 메시지에 담긴 SDP로 협상하며, 이 과정은 SIP 프로토콜 입문에서 설명했습니다.

전화 음성 코덱: G.711과 Opus

G.711

G.711은 ITU-T가 정한 가장 기본적인 전화 음성 코덱입니다. 음성을 1초에 8,000번(8kHz) 샘플링하고 샘플 하나를 8비트로 로그 압축해 64kbps로 전송합니다. 압축 방식에 따라 μ-law(PCMU, 정적 페이로드 타입 0)와 A-law(PCMA, 8)가 있으며, μ-law는 북미·일본에서, A-law는 유럽을 비롯한 그 밖의 지역에서 주로 씁니다. 처리 부담이 거의 없고 전화망과 연결할 때 변환이 단순하지만, 대역폭이 크고 전화 대역(약 300~3,400Hz)의 협대역 음성만 담습니다.

Opus

Opus는 IETF가 RFC 6716으로 표준화한 코덱으로, 6kbps에서 510kbps까지 비트레이트를 조절하고 협대역부터 48kHz 전대역까지 다룹니다. 패킷 손실에 대비한 FEC(순방향 오류 정정)와 말이 없을 때 전송을 줄이는 DTX를 지원하며, WebRTC에서 G.711과 함께 필수 지원 코덱으로 정해져 있습니다. RTP에서는 동적 페이로드 타입을 쓰고, SDP에는 실제 대역과 관계없이 opus/48000/2로 적습니다.

통화 경로 가운데 한 구간이라도 협대역 코덱을 거치면, 그 뒤 구간에서 광대역 코덱을 써도 잃어버린 고음역은 돌아오지 않습니다. 일반 전화망에서 걸려 오는 통화를 AI가 받는 구조라면 협대역 음성을 전제로 설계하는 것이 현실적입니다.

패킷 크기와 대역폭 계산

G.711을 20ms 간격(a=ptime:20)으로 보내면 패킷 하나에 8,000 × 0.02 = 160개 샘플, 즉 160바이트의 음성이 담기고 타임스탬프는 패킷마다 160씩 늘어납니다. 여기에 RTP 12바이트, UDP 8바이트, IPv4 20바이트 헤더 40바이트가 붙어 패킷 하나는 200바이트가 됩니다. 1초에 50개를 보내므로 200 × 50 × 8 = 80kbps가 한 방향에 필요합니다.

저비트레이트 코덱일수록 음성 데이터보다 헤더가 차지하는 비율이 커집니다. 동시통화가 많다면 통화 수 × 한 방향 대역폭을 송신과 수신 각각에 확보하고, 하위 계층 헤더와 여유분을 더해 회선 용량을 잡습니다.

전화 음성이 AI 모델로 흘러가는 방식

1. 1지터 버퍼: 들쭉날쭉 도착한 패킷을 순서대로 정렬하고 일정한 간격으로 꺼냅니다. 버퍼가 크면 끊김은 줄지만 지연이 늘어납니다.
2. 2디코딩: G.711 바이트를 16비트 선형 PCM으로 되돌립니다.
3. 3형식 변환: 모델에 따라 16kHz·24kHz PCM을 요구하기도 하고 G.711을 그대로 받기도 합니다. 8kHz 음성을 높은 샘플레이트로 올려도 없던 고음역이 생기지는 않으며, 협대역이 인식에 주는 영향은 전화 음성 인식이 어려운 이유에서 다룹니다.
4. 4실시간 스트리밍: 음성을 짧은 단위로 계속 모델에 흘려보냅니다. 음성-음성 모델은 들으면서 응답 음성을 바로 만들고, STT·LLM·TTS 연결형은 단계별로 처리합니다. 구조 차이는 Speech-to-Speech vs STT·LLM·TTS에서 비교합니다.
5. 5역변환: 응답 음성을 8kHz로 낮추고 통화 코덱으로 인코딩해 RTP로 보냅니다. 고객이 AI 응답 도중에 말을 시작하면 재생 중인 음성을 멈추는 처리도 이 단계와 맞물려 있습니다.

각 단계는 조금씩 지연을 더하므로, 버퍼 크기와 패킷 간격은 응답 속도와 함께 설계해야 합니다. 지연이 어느 구간에서 쌓이는지는 AI 전화 응답 지연은 어디서 생길까에서 나누어 봅니다.

통화 품질을 좌우하는 요소

• 지터: 패킷 도착 간격의 흔들림입니다. 지터 버퍼로 흡수하되, 버퍼를 키울수록 지연이 늘어납니다.
• 패킷 손실: 빠진 구간은 PLC(패킷 손실 은닉)로 메웁니다. Opus는 FEC로 일부 손실을 복원할 수 있습니다.
• 트랜스코딩: 경로 중간에서 코덱 변환이 여러 번 일어나면 음질이 떨어지고 지연이 늘어납니다. 가능하면 구간마다 같은 코덱을 쓰도록 협상합니다.
• 에코: 스피커폰이나 수화기에서 AI 음성이 되돌아오면 AI가 자기 목소리를 고객 발화로 착각할 수 있어 에코 제거가 중요합니다.
• 암호화: SRTP(RFC 3711)로 음성을 암호화하며, 키는 TLS로 보호한 SIP의 SDP(SDES)나 DTLS-SRTP로 주고받습니다.

KAT Cloud에서 RTP와 코덱 다루기

KAT Cloud는 표준 SIP/2.0·RTP·DTMF로 기존 PBX나 자체 음성 서버를 연결하고, 통화 음성을 음성 AI 모델과 양방향 실시간으로 연결합니다. 음성 모델은 제공사별 14종 가운데 고를 수 있습니다(AI 모델). SIP로 직접 연결할 때 쓸 코덱, 패킷 간격, 암호화 여부 같은 미디어 조건은 KAT Cloud 콘솔 또는 도입 문의로 확인합니다.

통화가 끝난 뒤 통화 기록 API로 받는 녹음 파일은 audio/wav 형식이며, 통화 유형에 따라 AI 구간(recordingAI)과 직원 구간(recordingDirect)으로 나뉘어 제공됩니다. 녹음 URL은 발급 후 1시간 뒤 만료되므로 보관이 필요하면 바로 내려받아 저장해야 합니다(통화 기록 API).

자주 묻는 질문

전화 음성은 왜 8kHz인가요?

기존 전화망은 말소리를 알아듣는 데 필요한 약 300~3,400Hz 대역을 전달하도록 설계되었고, 이 대역을 디지털로 담기 위해 8kHz 샘플링을 표준으로 삼았습니다. G.711이 이 방식이며, 지금도 전화망과 연결되는 구간에서는 8kHz 협대역 음성이 널리 쓰입니다.

G.711과 Opus 중 어느 쪽이 AI 전화에 좋은가요?

전화망과 연결되는 구간이 있다면 그 구간의 음성은 협대역이므로 코덱을 바꿔도 음성 대역이 넓어지지 않습니다. G.711은 변환이 단순하고 호환성이 높으며, Opus는 대역폭이 제한되거나 손실이 많은 네트워크에서 유리합니다. KAT Cloud와 SIP로 연결할 때 쓸 코덱은 콘솔 또는 도입 문의로 확인합니다.

통화 한 회선에 필요한 대역폭은 얼마인가요?

G.711을 20ms 패킷으로 보내면 IP·UDP·RTP 헤더를 포함해 송신과 수신에 각각 약 80kbps가 필요합니다. 실제 회선 용량은 여기에 이더넷 같은 하위 계층 헤더와 동시 통화 수, 여유분을 더해 잡습니다.