DTMF란? 전화 키패드 입력을 AI 에이전트가 받는 방법

DTMF(Dual-Tone Multi-Frequency)는 전화 키패드의 숫자와 기호를 서로 다른 두 주파수를 섞은 소리로 표현하는 신호 방식입니다. 인터넷전화에서는 이 소리를 음성에 그대로 싣는 인밴드 방식, RTP 이벤트 패킷으로 보내는 RFC 4733 방식, SIP INFO 메시지로 보내는 방식이 쓰입니다. AI 에이전트가 키패드 입력을 안정적으로 받으려면 음성 모델에 톤을 들려주기보다, 미디어 계층에서 DTMF를 숫자 이벤트로 바꿔 대화 흐름에 넘기는 구조가 적합합니다.

DTMF의 원리: 두 주파수의 조합

키 하나를 누르면 낮은 주파수 그룹(행)에서 하나, 높은 주파수 그룹(열)에서 하나를 골라 두 소리를 동시에 냅니다. 예를 들어 5번 키는 770Hz와 1336Hz가 함께 울리는 소리입니다.

사람 목소리나 음악에서 이 두 주파수가 정확히 함께 지속되는 경우는 드물기 때문에, 수신 측은 말소리와 키 입력을 구분할 수 있습니다. A~D 키는 일반 전화기에는 없지만 표준에는 정의되어 있습니다.

DTMF를 전달하는 세 가지 방식

인밴드

키 톤을 음성과 똑같이 RTP 음성 패킷에 실어 보냅니다. G.711처럼 압축 손실이 적은 코덱에서는 대체로 전달되지만, G.729 같은 저비트레이트 코덱이나 잡음 제거·자동 음량 조절을 거치면 톤이 일그러져 인식에 실패할 수 있습니다. 받는 쪽은 오디오를 분석하는 톤 검출기가 있어야 합니다.

RFC 4733

RFC 4733(이전 RFC 2833을 대체한 개정판)은 키 입력을 소리가 아니라 "몇 번 키가 얼마 동안 눌렸다"는 이벤트로 RTP에 실어 보냅니다. 코덱과 관계없이 정확하게 전달되고, 음성 스트림과 같은 경로로 흐르므로 시점도 맞습니다. 사용하려면 SIP의 SDP 협상에서 양쪽이 telephone-event를 합의해야 합니다. SDP 협상의 기본은 SIP 프로토콜 입문에서 설명했습니다.

SIP INFO

통화 중에 SIP INFO 요청(RFC 6086)으로 키 입력을 따로 보냅니다. 신호 서버에서 바로 확인할 수 있다는 장점이 있지만, 본문 형식(예: application/dtmf-relay)이 장비마다 달라 양쪽이 같은 형식을 쓰는지 확인해야 합니다.

RFC 4733 이벤트 들여다보기

RFC 4733 방식은 SDP에서 다음처럼 협상합니다. 101은 흔히 쓰는 동적 페이로드 타입 번호이고, 0-16은 지원하는 이벤트 범위입니다.

m=audio 49170 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

이벤트 패킷에는 이벤트 코드, 종료 표시(E 비트), 음량, 지속 시간이 담깁니다. 키 하나를 누르는 동안 같은 타임스탬프로 지속 시간이 늘어난 패킷이 반복해서 오고, 손을 떼면 종료 표시가 켜진 패킷이 보통 세 번 전송됩니다. 받는 쪽은 타임스탬프로 같은 입력을 묶어 키 하나로 처리합니다. RTP 패킷 구조 자체는 RTP와 음성 코덱에서 다룹니다.

AI 에이전트가 키패드 입력을 받는 구조

음성 AI 모델은 사람의 말을 이해하도록 만들어져 있어, 키 톤을 정확한 숫자로 알아듣는다고 기대하기 어렵습니다. 그래서 일반적으로 미디어 계층이나 음성 서버가 DTMF를 감지해 "2", "#" 같은 이벤트로 바꾸고, 애플리케이션이 이 이벤트를 대화 흐름에 넣습니다.

대화형 AI가 있는데도 키패드 입력이 필요한 이유는 분명합니다. 주변이 시끄러워 말소리가 잘 들리지 않을 때, 주문번호처럼 긴 숫자열을 한 자리도 틀리지 않고 받아야 할 때, 고객이 주변 사람 앞에서 생년월일 같은 정보를 소리 내어 말하기 꺼릴 때는 음성보다 키 입력이 정확하고 편합니다. 음성 인식으로 받은 숫자는 "일"과 "이"처럼 비슷한 발음 때문에 틀릴 수 있지만, DTMF 이벤트는 누른 키가 그대로 전달됩니다.

키패드 입력을 쓰는 대표적인 설계는 다음과 같습니다.

• 메뉴 선택: "예약은 1번, 변경은 2번"처럼 한 자리 입력을 받습니다.
• 여러 자리 입력: 생년월일이나 주문번호처럼 길이가 있는 값은 종료 키(#), 자릿수 사이 대기 시간, 최대 자릿수를 함께 정합니다.
• 확인 단계: 입력한 숫자를 다시 읽어 주고 맞는지 확인합니다.
• 음성과 키 입력 병행: 고객이 말로 답하든 키를 누르든 같은 값으로 받아들이면 이용이 편해집니다.

설계할 때 주의할 점

• 중복 인식: 인밴드 톤과 RFC 4733 이벤트가 함께 전달되면 같은 키가 두 번 인식될 수 있습니다. 통화 구간마다 한 방식으로 통일합니다.
• 협상 실패: 한쪽이 SDP에 telephone-event를 넣지 않으면 RFC 4733 이벤트가 오지 않습니다. 키 입력이 전혀 인식되지 않으면 SDP부터 확인합니다.
• 코덱 구간: 경로 중간에 압축 코덱 구간이 있으면 인밴드 톤이 손상될 수 있습니다.
• 시간 초과와 재시도: 키를 누르는 속도는 사람마다 다릅니다. 입력이 없을 때 다시 안내하는 횟수와, 끝내 입력이 없을 때 직원 연결이나 음성 응답으로 넘기는 경로를 정해 둡니다.
• 민감 정보: 카드번호나 비밀번호를 키패드로 받는다면 로그, 받아쓰기, 녹음에 남지 않도록 설계해야 합니다. 인밴드 톤은 녹음 파일에 소리로 남아 나중에 숫자로 복원될 수 있습니다. 수집 최소화 원칙은 AI 전화와 개인정보에서 다룹니다.

KAT Cloud에서 DTMF 다루기

KAT Cloud는 표준 SIP/2.0·RTP·DTMF로 기존 PBX나 자체 음성 서버를 연결할 수 있습니다. 이 구성에서는 SIP로 연결한 PBX나 음성 서버가 키패드 입력을 받아 IVR 메뉴나 AI 대화 흐름에 활용합니다. 어떤 DTMF 전달 방식으로 연결할지는 SIP 접속 정보와 함께 KAT Cloud 콘솔 또는 도입 문의로 확인합니다. 콘솔에서 설정하는 AI 에이전트 응대에 키패드 입력을 함께 쓰려는 경우에도, 설정 가능한 범위를 같은 경로로 먼저 확인하는 것이 좋습니다.

자주 묻는 질문

DTMF와 터치톤은 같은 것인가요?

터치톤은 DTMF 방식 전화를 부르던 상표명에서 나온 말로, 일반적으로 DTMF와 같은 뜻으로 씁니다. 두 말 모두 키패드를 누를 때 나는 두 주파수 조합의 신호를 가리킵니다.

RFC 2833과 RFC 4733은 무엇이 다른가요?

RFC 4733은 RFC 2833을 대체한 개정판이며, telephone-event 페이로드로 DTMF를 RTP 이벤트로 보내는 방식은 같습니다. 장비 설정 화면에 "RFC 2833"으로 표기된 항목도 보통 이 방식을 뜻합니다.

음성 AI 모델이 DTMF 톤을 직접 알아들을 수 있나요?

음성 AI 모델은 사람의 말을 이해하도록 만들어져 있어 DTMF 톤을 정확한 숫자로 인식한다고 보장하기 어렵습니다. 그래서 미디어 계층이나 음성 서버가 DTMF를 감지해 숫자 이벤트로 바꾼 뒤 AI 대화 흐름에 넘기는 구조가 일반적입니다.