„Ich drücke die 1, aber nichts passiert“ – Tastentöne bei VoIP

„Bitte geben Sie Ihre Kundennummer ein.“ Man tippt, und nichts passiert. Oder das Menü versteht „11“, obwohl man einmal die 1 gedrückt hat. Wer mit Telefonanlagen zu tun hat, kennt diese Störung. Sie ist lästig, weil der Anruf selbst ja funktioniert: Man hört sich, nur die Tasten kommen nicht an.

Die Ursache ist fast immer dieselbe: Telefon, Anlage und Provider sind sich nicht einig, wie die Tastentöne übertragen werden. Davon gibt es nämlich drei Arten. Ich habe das in einem kleinen Labor nachgestellt; alle Ausgaben in diesem Beitrag sind echt.

Was ein Tastenton eigentlich ist

Der Fachbegriff ist DTMF, „Dual Tone Multi Frequency“. Jede Taste erzeugt zwei Töne gleichzeitig, einen tiefen und einen hohen:

Die 1 ist also 697 Hz plus 1209 Hz. Die Tasten A bis D gibt es auf normalen Telefonen nicht, sie wurden früher für Sonderzwecke genutzt. Im analogen Telefonnetz war das einfach: Die Töne liefen durch die Leitung wie die Stimme, und das Sprachmenü am anderen Ende hat zugehört.

Die drei Wege bei VoIP

Bei Internettelefonie gibt es drei Verfahren, und genau da beginnt das Problem.

1. Inband: der Ton steckt in der Sprache. Das Telefon erzeugt die beiden Töne und schickt sie mit der Sprache mit, wie früher. Das klingt am einfachsten, funktioniert aber nur zuverlässig, wenn die Sprache unverändert ankommt. Moderne Codecs komprimieren die Sprache und sind auf menschliche Stimmen optimiert, nicht auf reine Sinustöne. Dabei können die Töne so verformt werden, dass die Gegenseite sie nicht mehr erkennt. Auch Paketverluste schneiden Töne ab.

2. RFC 4733: der Ton als eigenes Datenpaket. Das Telefon schickt keinen Ton, sondern eine kleine Nachricht im Sprachstrom: „Taste 1 gedrückt, so lange.“ Das ist das heute übliche Verfahren, früher als RFC 2833 bekannt. Ob beide Seiten es können, handeln sie beim Anrufaufbau aus. In der Verbindungsbeschreibung (SDP) steht dann eine Zeile mit telephone-event.

3. SIP INFO: der Ton als SIP-Nachricht. Das Telefon schickt für jede Taste eine eigene Nachricht über die Signalisierung, also auf dem Weg, auf dem auch der Anruf auf- und abgebaut wird. Das funktioniert, ist aber nicht einheitlich genormt; es gibt mehrere Formate, und nicht jede Gegenstelle versteht jedes.

Der Labortest

Im Labor laufen eine Asterisk-Telefonanlage und ein Softphone (baresip) in einem abgeschotteten Docker-Netz. Die Anlage hat eine Nummer 700, die vier Ziffern abfragt und ins Protokoll schreibt, was angekommen ist:

exten => 700,1,Answer()
 same => n,Wait(1)
 same => n,Read(PIN,,4,,1,8)
 same => n,Verbose(1,Eingegebene PIN: "${PIN}")
 same => n,Hangup()

Das Telefon ruft an und tippt 1234. Dann stelle ich auf beiden Seiten verschiedene Verfahren ein.

Fall 1: beide sprechen RFC 4733

Beim Anrufaufbau bieten beide telephone-event an:

m=audio 20060 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Die Zeile rtpmap:101 telephone-event/8000 bedeutet: Tastendrücke kommen als eigene Pakete mit der Typnummer 101. Asterisk protokolliert jede Taste sauber mit Dauer:

DTMF begin '1' received on PJSIP/1001-00000000
DTMF end '1' received on PJSIP/1001-00000000, duration 260 ms
DTMF begin '2' received on PJSIP/1001-00000000
DTMF end '2' received on PJSIP/1001-00000000, duration 260 ms
...
Eingegebene PIN: "1234"

So soll es sein.

Fall 2: die Anlage erwartet SIP INFO, das Telefon schickt RFC 4733

Jetzt stelle ich die Anlage auf dtmf_mode=info. Das Telefon bietet weiter telephone-event an, aber die Antwort der Anlage enthält es nicht mehr:

SIP/2.0 200 OK
...
m=audio 10058 RTP/AVP 8
a=rtpmap:8 PCMA/8000

Das Telefon meldet trotzdem munter, dass es Tasten sendet:

audio: send DTMF digit: '1'
audio: send DTMF digit end: '1'
...

In der Anlage kommt nichts an. Das Protokoll enthält keine einzige DTMF-Zeile, nur:

Eingegebene PIN: ""

Das ist der klassische Fall „Ich drücke, aber nichts passiert“. Beide Seiten machen für sich alles richtig, nur eben nicht dasselbe.

Fall 3: beide sprechen SIP INFO

Stelle ich auch das Telefon auf SIP INFO um, schickt es für jede Taste so eine Nachricht:

INFO sip:172.30.0.10:5060 SIP/2.0
...
Content-Type: application/dtmf-relay
Content-Length: 24

Signal=1
Duration=250

Und die Anlage versteht wieder alles: Eingegebene PIN: "1234".

Fall 4: Töne in der Sprache, aber die Anlage hört nicht hin

Für den Inband-Test spielt das Telefon statt einer Testmelodie eine Tondatei mit den Tönen für 1, 2, 3 und 4 ab, also echte Tastentöne in der Sprache. Die Anlage steht auf RFC 4733 und wertet die Sprache deshalb nicht aus:

Eingegebene PIN: ""

Stelle ich die Anlage auf dtmf_mode=inband, erkennt sie die Töne mit dem Codec G.711 (PCMA) zuverlässig: Eingegebene PIN: "1234".

Fall 5: Töne in der Sprache, mit komprimiertem Codec

Jetzt derselbe Test mit dem Codec GSM, der die Sprache auf 13 kbit/s zusammenpresst. Der Anruf steht, die Sprache läuft, das Telefon schickt dieselbe Tondatei. Ergebnis:

Eingegebene PIN: ""

Keine einzige Taste erkannt. Die Kompression hat die Töne so verändert, dass die Erkennung in der Anlage nichts mehr damit anfangen kann. Genau deshalb ist Inband bei VoIP eine schlechte Idee, sobald irgendwo auf dem Weg ein komprimierender Codec im Spiel ist.

Die Ergebnisse auf einen Blick

Später habe ich noch alle übrigen Kombinationen durchgespielt, jeweils mit G.711 und GSM. Dabei kam eine Überraschung heraus: Asterisk nimmt SIP INFO immer an, auch wenn die Anlage auf RFC 4733, Inband oder Auto steht. Umgekehrt gilt das nicht: Steht die Anlage auf SIP INFO, ignoriert sie RTP-Events. Auf dieses Entgegenkommen sollte man sich bei anderen Anlagen und Providern aber nicht verlassen.

Selbst ausprobieren: Im Sprachlabor kannst du alle Kombinationen aus dem Labor durchspielen, mit Tastatur, Tastentönen und dem, was auf der Leitung passiert.

Und warum kommen Ziffern doppelt an?

Das Gegenstück zum Verschlucken ist das Verdoppeln: Man drückt einmal die 1, das Menü versteht 11. Das passiert, wenn eine Taste auf zwei Wegen gleichzeitig ankommt. Typisch ist ein Telefon oder Gateway, das den Ton in der Sprache lässt und zusätzlich eine RFC-4733-Nachricht schickt, während die Gegenstelle beides auswertet. Manche Geräte haben dafür eine Einstellung wie „DTMF auch in der Sprache unterdrücken“.

Was in der Praxis hilft

• RFC 4733 überall ist die beste Wahl. Fast jeder Provider, jede Anlage und jedes Telefon kann es. In Asterisk heißt die Einstellung dtmf_mode=rfc4733, in vielen Telefonen „RFC 2833“ oder „RTP-Event“.
• Einheitlich einstellen: Telefon, Anlage und Provider-Strecke sollten dasselbe Verfahren nutzen. „Auto“ funktioniert oft, aber nicht immer.
• Inband nur als Notlösung, und dann nur mit G.711 auf der ganzen Strecke.
• Im SIP-Trace nachsehen: Steht in Angebot und Antwort telephone-event? Fehlt es in der Antwort, ist die Ursache gefunden. Wie man Traces liest, steht in SIP-Traces lesen lernen.
• Bei Fax-Geräten und Alarmanlagen an VoIP-Anschlüssen gelten ähnliche Probleme, weil auch dort Töne durch die Sprachstrecke müssen. Mehr dazu in Fax über SIP.

Fazit

Die Tasten kommen nicht an, wenn die Geräte unterschiedliche Sprachen sprechen. Wer überall RFC 4733 einstellt, hat das Problem in den allermeisten Fällen gelöst. Und wer es nicht weiß, schaut in den SIP-Trace: Die Zeile telephone-event verrät, ob sich beide Seiten geeinigt haben.

Labor: Asterisk 20 und baresip 1.1 in Docker auf meinem Entwicklungsrechner, ohne Verbindung ins Internet. Quellen: RFC 4733 (RTP Payload for DTMF Digits) · RFC 6086 (SIP INFO) · ITU-T Q.23 (Tastenwahl-Frequenzen)

Trace lesen lassen statt selbst grübeln: Lade deinen SIP-/VoIP-Mitschnitt bei der Pcap-Diagnose hoch und bekomme eine klare technische Einschätzung zurück — wo es hakt, auf welcher Seite, was der nächste Schritt ist. Die erste Analyse pro E-Mail-Adresse ist kostenlos.