Les DTMF
Les DTMF (Dual Tone Multi-Frequency) font référence aux sons produits par l'appui sur les touches des téléphones. (En France on parle aussi de FV - Fréquences Vocales).
Les postes à cadrans tels que le Socotel S63 utilisaient la numérotation par impulsion qui correspondaient à des coupures électriques dont le nombre était lié au chiffre choisi (chiffre 7=> 7 coupures, 0=> 10 coupures).
Pensés par AT&T dès 1963, les DTMF avaient pour vocation à remplacer la numérotation par impulsion par une tonalité différente (en fait deux tonalités -> dual-tone / DT ) pour chaque chiffre formant le numéro à appeler. L'évolution des usages a fait que les touches n'ont plus servi qu'à numéroter, mais aussi à interagir avec des services vocaux automatisés comme les SVI (serveur vocaux interactifs), les messageries vocales etc...
Les DTMF fonctionnaient parfaitement sur les réseaux analogiques et numériques qui garantissaient une qualité audio constante (64 kb, 8000 Hz)
L'arrivée de la voix sur IP et de la compression de l'audio a rendu la détection des tonalités DTMF plus hasardeuse, les tonalités étant potentiellement altérées par la compression.
La norme RFC 2833 (https://datatracker.ietf.org/doc/html/rfc2833) a été définie pour permettre de séparer les DTMF de la conversation audio permettant ainsi de compresser l'audio sans altérer la signalisation DTMF.
La RFC 2833 a ensuite été remplacée par la RFC 4733, aujourd'hui on parle bien souvent toujours de RFC 2833 même s'il s'agit d'une implémentation de la RFC 4733.
| f1\f2 | 1 209 Hz | 1 336 Hz | 1 477 Hz | 1 633 Hz |
|---|---|---|---|---|
| 697 Hz | A | |||
| 770 Hz | B | |||
| 852 Hz | C | |||
| 941 Hz | D |
Selon l'origine de la communication et les équipements parcourus, le signal DTMF pouvait donc être dans un flux séparé dès le départ ou séparé par un équipement ayant extrait les tonalités du flux audio. Selon les situations l'équipement ayant extrait les tonalités du flux audio pouvait les laisser ou les supprimer plus ou moins efficacement. Au final il arrivait que les DTMF soient "reçus" 2 fois, la première dans le signal audio, la seconde par la signalisation ajoutée. Des techniques mixant des méthodes d'anti-rebond / durée du signal DTMF minimal dans l'audio VS signalisation DTMF permettaient de limiter cet effet, mais la fiabilité n'était pas totale.
Le choix du transport des DTMF
Afin que l'ensemble des équipements puissent être supportés selon leur capacité à supporter les différents transports de DTMF, la décision est prise avant l'établissement de la communication, l'équipement émetteur de l'INVITE définissant ses capacités via le protocole SDP, le récepteur lui proposant à son tour ses capacités.
Le protocole SDP (Session Description Protocol) est un protocole de description des paramètres d'initialisation d'une session d'échange de médias en flux (streaming). Il ne porte pas le média en lui-même et sert à la négociation entre l'émetteur et le destinataire. Le SDP décrit les paramètres pour l'échanges de médias entre 2 équipements. Il est défini par la RFC 4566.
Exemples de charges SDP dans un SIP INVITE
Request-Line: INVITE sip:74422@192.168.1.207:5060 SIP/2.0
(...)
Message Body
Session Description Protocol
(...)
Media Description, name and address (m): audio 39630 RTP/AVP 8 0
Media Type: audio
Media Port: 39630
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.711 PCMU
Media Attribute (a): sendrecv
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): ptime:20Inband DTMF
Cet exemple montre l'appel depuis un terminal basique ne proposant aucun support spécifique des DTMFs qui seront donc à extraire du flux audio. Seuls les codecs audios G.711A (PCMA:8) et G.711u (PCMU:0) sont offerts à la négociation.
L'équipement recevant cet INVITE proposera via un SDP ses capacités, et le premier match commun sera utilisé (à savoir ici de préférence PCMA si l'équipement recevant l'accepte, sinon PCMU). La détection des DTMFs sera entièrement à la charge du récepteur.
DTMF SIP-INFO
Cet exemple montre un terminal proposant le support des DTMF via l'envoi de messages SIP-INFO, indiqué par Media Attribute (a) : sendrecv.
Ci-dessous la signalisation via un message SIP INFO d'un DTMF "2".
Session Initiation Protocol (INFO)
Request-Line: INFO sip:74422@192.168.1.207:5060;transport=udp SIP/2.0
Message Header
(...)
Content-Type: application/dtmf-relay
Message Body
Signal=2\r\n
Duration=1440
Request-Line: INVITE sip:74422@192.168.1.207:5060 SIP/2.0
(...)
Message Body
Session Description Protocol
(...)
Media Description, name and address (m): audio 39630 RTP/AVP 8 0
Media Type: audio
Media Port: 39630
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.711 PCMU
Media Attribute (a): sendrecv
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): ptime:20
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:74422@192.168.1.207:5060 SIP/2.0
(...)
Message Body
Session Description Protocol
Media Description, name and address (m): audio 39630 RTP/AVP 8 0 101
Media Type: audio
Media Port: 39630
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.711 PCMU
Media Format: DynamicRTP-Type-101
Media Attribute (a): sendrecv
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): ptime:20
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-11
RFC 2833
Ici l'émetteur supporte la RFC 2833 en proposant les telephone-event avec un payload 101 (la plupart des terminaux utilisent un payload 101 mais ce n'est pas normé, ainsi le serveur nativIP accepte et peut proposer un autre payload pour s'adapter aux équipements connectés.)
Dans le détail le format accepté est 0 à 11 soit les touches 0 à 9, ainsi que * et #. (Les autres possibilités 12 à 16 sont A, B, D, E, et la touche Flashing dont ne dispose pas cet équipement).
Ci-dessus la matérialisation d'un DTMF 8 via les RTP EVENT liés.
Ci-dessous les détails d'un RTP Event flaggant la fin de l'event lié à un DTMF 8.
nativIP serveur et les DTMFs
nativIP serveur négocie automatiquement au mieux les DTMFs en proposant le support des RFC 4733/2833 mais aussi des messages SIP INFO (et de la variante CISCO) ou l'extraction des DTMFs du flux audio. Par défaut, la négociation est totalement automatisée pour les appels entrants et la RFC 4733 est proposée pour les appels sortants. Via configuration toutes les possibilités sont offertes.