DTMF en VoIP: Métodos, Estándares y Configuraciones Prácticas
El DTMF (Dual Tone Multi-Frequency) es la base de la marcación por tonos en telefonía. En el mundo de la VoIP y SIP, la correcta transmisión de estos tonos es esencial para interactuar con sistemas IVR, bancos, call centers y cualquier aplicación que requiera ingreso de dígitos durante la llamada.
DTMF fue introducido en 1963 por Bell System bajo la marca Touch-Tone en Estados Unidos. Su lanzamiento reemplazó el viejo sistema de discado por pulsos (rotary dial) para que que los teléfonos tuvieran teclados numéricos con tonos diferenciados.
Cada tecla producía la combinación de dos frecuencias (de ahí el nombre “dual-tone”), lo que facilitó la marcación más rápida y confiable. Posteriormente, en los años 80 y 90, el uso de DTMF se expandió para interactuar con servicios automáticos de voz, sistemas bancarios por teléfono y centrales de llamadas, marcando el inicio de los IVR modernos.
Métodos de Transmisión de DTMF
A lo largo del tiempo se han definido distintos métodos y estándares para enviar DTMF en redes IP, cada uno con ventajas y desventajas. Existen tres enfoques principales:
- In-band (Audio puro) Los tonos viajan como audio dentro del mismo flujo RTP. Requiere códecs sin compresión (ej. G.711).
- RFC 2833 / 4733 (RTP Events) Los tonos no viajan como audio, sino como eventos RTP. Es el método más usado porque resiste la compresión y mantiene sincronización.
- SIP INFO (Out-of-band por señalización) Los tonos se envían como mensajes SIP INFO a través de la señalización. Es confiable en algunos entornos, pero puede sufrir problemas de sincronización y depende de que los SIP proxies los manejen adecuadamente.
Tabla comparativa
| Método | Descripción | Ventajas | Desventajas | Ejemplo de Uso |
| In-band (Audio) | Tonos enviados como audio en el flujo RTP | Fácil de implementar, funciona con equipos antiguos | No soporta códecs comprimidos (G.729, GSM) | PBX legacy con G.711 |
| RFC 2833 | Tonos enviados como eventos RTP (obsoleto pero vigente) | Estándar más adoptado, soporta compresión | Depende de soporte de fabricante | ITSPs que aún lo exigen |
| RFC 4733/4734 | Evolución de 2833 con más eventos. | Flexible, más completo | Implementación lenta en algunos fabricantes | Sistemas modernos VoIP |
| SIP INFO | Tonos enviados vía señalización SIP | Independiente del códec de audio | Problemas de sincronización, expuesto a proxies SIP | Integraciones con bancos, IVRs |
Soporte de Fabricantes
El soporte de DTMF ha sido implementado de forma distinta por los fabricantes, siendo anunciadas compatibilidades y limitaciones en cada caso.
| Fabricante | Soporte DTMF |
|---|---|
| Cisco | RFC 2833 y SIP INFO (configurable), soporte limitado de 4733 en versiones más nuevas |
| Avaya | RFC 2833 como preferido, SIP INFO opcional |
| Asterisk | RFC 2833 (default), In-band y SIP INFO configurables |
| FreeSWITCH | RFC 2833/4733, SIP INFO y In-band |
| Grandstream | RFC 2833 y SIP INFO, algunos modelos con soporte 4733 |
| Yealink | RFC 2833 y SIP INFO, con opción de in-band |
Ejemplos de Configuración
A continuación serán mostradas configuraciones prácticas de troncales en diferentes plataformas de telefonía IP. En cada caso se ilustrará cómo es soportada la transmisión de tonos DTMF mediante los distintos métodos disponibles (in-band, RFC 2833/4733 y SIP INFO).
Se presentan ejemplos correspondientes a Asterisk, FreeSWITCH y Cisco, con el fin de evidenciar cómo es aplicada la misma funcionalidad bajo distintos entornos y fabricantes.
Para asterisk:
[trunk-lavariega]
type=peer
host=sip.provider.com
username=miusuario
secret=miclave
dtmfmode=rfc2833 ; Opciones: inband, rfc2833, info
context=from-trunk
FreeSWITCH (Sofia SIP profile)
<gateway name="trunk-itsp">
<param name="username" value="miusuario"/> <param name="password" value="miclave"/>
<param name="proxy" value="sip.provider.com"/>
<param name="dtmf-type" value="rfc2833"/> </gateway>
🔹 Cisco (Dial-Peer VoIP)
dial-peer voice 100 voip
destination-pattern 9T
session target ipv4:10.10.10.10
dtmf-relay rtp-nte ! Opciones: rtp-nte (RFC2833), sip-notify, h245-signal, h245-alphanumeric
codec g711ulaw
no vadConclusión
Aunque RFC 4733 es el estándar más moderno, muchos proveedores de servicios (ITSPs) aún requieren RFC 2833. Por eso, la mayoría de fabricantes ofrecen compatibilidad múltiple, permitiendo elegir entre in-band, RFC 2833/4733 o SIP INFO. La mejor práctica es usar RFC 2833/4733 cuando sea posible, y dejar SIP INFO como alternativa en casos específicos.
