Zusammenfassung

  • Die phone-string aus RFC 3601 mischt DTMF, Pause, tonewait und rein visuelle Separatoren. Ein local-phone kann Amtskennziffer, Carrier-Zugang, Dienstpasswort und Eingaben nach Verbindungsaufbau enthalten.
  • Herkunft, Klassifikation, Kontext, Freigabe, Geräteaktionen, Signalisierung, Verbindung und Dienstergebnis brauchen getrennte Belege. Kein früher Status darf für einen späteren sprechen.

Ein Migrationsskript entfernt Punkte und Bindestriche. Das ist im Sinne von RFC 3601 vertretbar, denn diese Zeichen dürfen keine Aktion auslösen. Dann entfernt dasselbe Skript auch Buchstaben. Plötzlich fehlen Pause und Warten. Aus einem Vergleichsschritt ist ein Eingriff in die Ausführung geworden, obwohl die Spalte weiterhin „Telefonnummer“ heißt.

RFC 3601 erschien im September 2003 als Standards Track und definiert eine Textnotation für Wählfolgen sowie wählbare GSTN/E.164-Adressen. Eine Dial Sequence ist eine Folge von DTMF-Elementen und Aktionen eines Menschen oder Geräts. Ihre phone-string umfasst Ziffern, #, *, A-D, p für Pause, w für tonewait sowie und . als written separators.

Die Gruppen haben verschiedene Semantik. Separatoren verbessern nur die Lesbarkeit und dürfen keine Aktion bewirken; Implementierungen können sie einfügen oder entfernen. Pause und tonewait verändern den Ablauf. Eine Normalisierung muss daher zuerst den Typ kennen. Sonst behandelt sie Steuerzeichen wie Typografie oder Typografie wie Steuerzeichen.

Auch die Steuerung ist nicht universell. Der RFC empfiehlt für eine Pause eine Sekunde. tonewait soll bis zu einem Wählton oder einer anderen Anzeige warten, nach der weitere Zeichen verarbeitet werden dürfen; auch off-hook kann als solche Anzeige gelten. Die genaue Auslegung bleibt jedoch geräte- und implementierungsabhängig. Gleiche Eingabe bedeutet nicht identische Zeitfolge.

Damit endet die Aussagekraft des Parsers. Er belegt Syntax, nicht ausgegebene DTMF-Signale, reale Pausendauer oder das Ereignis, das Warten beendete. „tonewait erfüllt“ ist ein lokaler Detektorentscheid. Er weist weder die Gegenstelle nach noch den Verbindungsaufbau oder den Empfang späterer Zeichen.

Die zweite Trennung verläuft zwischen Sequenz und Adresse. gstn-phone ist global oder lokal. Ein global-phone beginnt mit + und repräsentiert wählbare numerische E.164-Adressen. Vollständige abstrakte E.164-Adressen besitzen laut RFC weitere, nicht wählbare Elemente und lassen sich nicht vollständig in diese Notation umsetzen. Das Pluszeichen kennzeichnet einen Namensraum, nicht sämtliche Eigenschaften einer abstrakten Adresse.

Ein local-phone hängt sichtbar vom Ort ab. Es kann exit-code und dial-number kombinieren. Zum exit-code können Amtszugang, Fernwahl-Carrier, Dienstpasswort und ähnliche Elemente gehören. Eine bytegleiche Kopie auf eine andere Nebenstellenanlage bewahrt nicht automatisch Wählplan, Betreiberregel oder Konfigurationsstand.

RFC 3966 schärfte später die Grenze: Eine tel URI ist ein Identifier, keine Anleitung, wie die Nummer erreicht wird. Sie impliziert weder Dialing-Semantik noch weltweite Erreichbarkeit. Wählfolgen, Pausen und post-dial wurden aus ihrem Umfang entfernt. Lokale Nummern benötigen phone-context; dieser beschreibt den Gültigkeitsbereich und ist kein Präfix, dessen Anhängen zuverlässig eine E.164-Nummer erzeugt.

RFC 4967 führte anschließend user=dialstring für SIP/SIPS ein. Eine Wählfolge existiert immer in einem Kontext und muss von einem User-Part mit denselben Zeichen unterscheidbar sein. RFC 6116 hält bei ENUM am führenden Plus einer vollständig qualifizierten E.164-Nummer fest und verbietet, lokal gewählte Ziffern als solchen Input auszugeben. Mehrere lokale Folgen können demselben globalen Ziel entsprechen.

Darum ist die Umwandlung jedes telefonähnlichen Feldes in eine tel URI keine reine Formatänderung. Zuerst kommt die Klassifikation: Identifier, global-phone, local-phone, Dial Sequence, Subadresse oder post-dial. Erst dann kann die Zielstruktur Adresse, Aktion und Geheimnis getrennt behandeln.

post-dial besitzt eine Voraussetzung. RFC 3601 beschreibt damit Zeichen, die nach hergestellter Verbindung zum Zielgerät gesendet werden, etwa an ein Menü. Ein gespeicherter post-dial-Wert beweist keine Verbindung. Ein Ausführungsnachweis muss zuerst Antwort oder Session-Aufbau und danach DTMF sowie Dienstreaktion verbinden.

Das Feld kann zudem Zugangsdaten tragen. Das RFC-Beispiel kombiniert Mailbox-ID und PIN; der Sicherheitsabschnitt warnt vor Offenlegung privater Codes in ungeschützt übertragenen Zeichenfolgen. Was im Adressbuch wie Kontaktdaten aussieht, kann zugleich Programm und Credential sein.

Sekundärsysteme vergrößern den Schaden. Suche, CRM-Export, Analytics, Debug-Log und Support-Screenshot kopieren den gesamten Wert. Alles zu maskieren zerstört forensische Verknüpfung; alles zu speichern verbreitet den Code. Besser sind getrennte Felder für öffentliche Adresse, Aktionsplan und geschützte Secret-Referenz. Logs behalten Hash, Struktur und Ereignisse statt Klartext.

Die Belegkette beginnt mit Lieferant, ursprünglichem Feldtyp, Rohwert-Hash und Zeit. Es folgen Klassifikation und Parser-Version. Der Kontextbeleg nennt Standort, PBX, Nummernplan, Carrier-Regel und Konfigurationsepoche. Jede Zeichenänderung wird dokumentiert. Vor Ausführung steht Freigabe. Währenddessen werden DTMF, Pausendauer und Auslöser des Wartens protokolliert. Route, Verbindung, post-dial und Geschäftsergebnis bleiben eigene Schichten.

So verlieren bequeme Begriffe ihre falsche Reichweite. Importiert ist nicht klassifiziert. Gültig ist nicht freigegeben. Gewählt ist nicht verbunden. Angenommen bestätigt nicht die erwartete Identität. Gesendete Tasten bestätigen keine Menüannahme. Präzision heißt, dass jeder Beleg nur seine Beobachtung trägt.