DTMF-Kompatibilität: Audiotöne, RFC 4733 und SIP INFO

Kurzantwort: Wählen Sie ein DTMF-Verfahren, das beide Gesprächsabschnitte und ihre Übergänge verstehen. Audiotöne, RTP-Ereignisse nach RFC 4733 und SIP INFO sind unterschiedliche Darstellungen. Ein hörbarer Ton beweist nicht die richtige Auswahl in der Anwendung. Prüfen Sie DTMF getrennt vom Verbindungsaufbau, insbesondere nach einer Weiterleitung. Ziel ist die korrekte Zuordnung eines Tastendrucks zum gewünschten Menüschritt.

Bei DTMF im Audio erkennt der Empfänger den Ton

Beim Verfahren im Audiokanal wird der Tastenton innerhalb des codierten Audios übertragen und vom Empfänger erkannt. [1] Trennen Sie Tonerzeugung, Übertragung und Erkennung als Prüfschritte. Prüfen Sie diesen Ablauf erneut, wenn Codec oder Medienverarbeitung wechseln. Anhören hilft bei der Untersuchung, sollte jedoch mit dem Anwendungsereignis der tatsächlichen Menüauswahl verbunden werden. Die Rückmeldung an den Nutzer darf eine falsch erkannte Auswahl nicht verdecken.

RFC 4733 beschreibt ein Telefonereignis

RFC 4733 überträgt Telefonereignisse als RTP-Nutzlast mit Ereigniscode, Dauer und Abschlussinformation. Die Nutzlastzuordnung wird etwa über SDP vereinbart. [1] Der Empfänger muss die Auswahl deshalb nicht ausschließlich akustisch erkennen. Prüfen Sie das ausgehandelte Ereignisformat gemeinsam mit der in der Anwendung ankommenden Auswahl. Setzen Sie die Anzahl der Netzpakete nicht mit Tastendrücken gleich; verbinden Sie den Ereignisablauf mit einem logischen Menüeingang.

SIP-INFO-Unterstützung bestätigt noch keinen passenden Inhalt

SIP INFO transportiert Anwendungsinformationen innerhalb einer Sitzung. [2] RFC 6086 beschreibt nicht standardisierte ältere DTMF-INFO-Verwendungen und das Info-Package-Rahmenwerk. [3] Beenden Sie die Abstimmung nicht bei „INFO wird unterstützt“. Dokumentieren Sie mit der Gegenseite Inhaltstyp, Bedeutung des Nachrichtenkörpers und Anwendungsverhalten. Methodenname und Inhaltsvertrag sind getrennte Prüfpunkte. Auch nach der Zustellung einer Nachricht muss überprüft werden, ob das Menü die richtige Aktion ausführt.

Erwartet ein Abschnitt RTP-Ereignisse und ein anderer INFO, beschreiben Sie den Übergang ausdrücklich. Die Zuordnung vom eingehenden Ereignis zur logischen Auswahl und ausgehenden Darstellung sollte sichtbar sein. Eine Umwandlung rechtfertigt nicht die Annahme, dass unverstandene Formate automatisch funktionieren. Dokumentieren Sie die akzeptierten Eingaben und erzeugten Ausgaben jeder Seite, einschließlich des Verhaltens ohne gemeinsame Darstellung.

Verfahren anhand derselben Abnahmefrage vergleichen

Die Tabelle erklärt kein Verfahren zum allgemeinen Sieger. Prüfen Sie, ob ein Tastendruck zum vorgesehenen Zeitpunkt das Zielmenü zum richtigen Schritt führt. Wiederholen Sie diese Frage für jede Richtung und Weiterleitungsgrenze. Erfolg im ersten Menü belegt nicht dieselbe Kompatibilität eines späteren Menüs. Verständliche Nutzerhinweise bei nicht unterstützten Fällen gehören ebenfalls in den Prüfplan.

Den Prüfsatz aus Nutzerverhalten ableiten

Prüfen Sie mehr als eine einzelne Taste. Verwenden Sie unterschiedliche Auswahlwerte, wiederholte Betätigung derselben Taste, schnelle Folgen, langes Drücken und Eingaben während einer Ansage. Schreiben Sie das erwartete Menüergebnis vorher auf. Vergleichen Sie erzeugte Eingabe und empfangenes Anwendungsereignis und prüfen Sie danach die Bestätigung an den Nutzer. Fehlende und doppelte Auswahl sind verschiedene Fehlerarten. Erfassen Sie sie getrennt, damit eine spätere Korrektur am ursprünglichen Verhalten überprüft werden kann.

Lokalisieren Sie die erste Abweichung: Hat die Quelle den Tastendruck erzeugt, der Übergang ihn umgesetzt, das Menü ihn empfangen und der Ablauf die richtige Aktion ausgeführt? Untersuchungsdaten benötigen weder geheime Codes noch Nummern realer Anrufer. Synthetische Eingaben können für den Vergleich von erwartetem und beobachtetem Ergebnis genügen. Halten Sie Aufgabe und Eingabe unverändert, während das verdächtige Verfahren untersucht wird.

Fiktives Beispiel: vom Empfangsmenü zum Mitarbeiter

Ein Hotelmenü nimmt eine Taste entgegen, um den Empfang zu erreichen. Beim ersten Versuch kommt die richtige Menüeingabe an. Danach leitet das Team den Anruf an ein Mitarbeitertelefon weiter und versucht eine weitere Menüauswahl. Ändert sich an dieser Grenze das DTMF-Verfahren, wird die Umwandlung gesondert geprüft. Ist ein Ton hörbar, ohne dass das Menü reagiert, bleibt die Unterscheidung zwischen gehörtem Audio und empfangenem Ereignis entscheidend.

Bei wiederholter Auswahl untersucht das Team, ob ein tatsächlicher zweiter Tastendruck oder dieselbe erneut verarbeitete Meldung vorliegt. Das Ergebnis nennt Richtung, Menü und Übergang, statt nur „DTMF funktioniert“ festzuhalten. Wird ein weiterer Telefonendpunkt eingebunden, dienen dieselben synthetischen Beispiele dem Vergleich mit der vorherigen Abnahme. Die Aufzeichnung sollte den geprüften Umfang erklären, ohne private Betriebskonfiguration offenzulegen.

Kompatibilitätscheckliste

• Gesendetes und akzeptiertes Verfahren jedes Gesprächsabschnitts erfassen.
• RTP-Ereignisvereinbarung oder INFO-Inhaltsvertrag überprüfen.
• Erkennung im Audio mit der tatsächlichen Anwendungsauswahl abgleichen.
• Wiederholte, schnelle, lange und während Ansagen erfolgende Eingaben prüfen.
• Unterscheidung zwischen erneutem Ereignisbericht und zweitem Tastendruck untersuchen.
• Prüfungen nach Weiterleitung und Wiederverbindung wiederholen.
• Synthetische Eingaben verwenden und geheime Codes aus Diagnoseaufzeichnungen ausschließen.

Häufige Fragen

Sind RFC 2833 und RFC 4733 dieselbe Bezeichnung? RFC 4733 ersetzt RFC 2833. [1] Prüfen Sie eine ältere Oberflächenbezeichnung anhand der Endpunktdokumentation und der ausgehandelten Darstellung. Leiten Sie das Verhalten nicht allein aus dem Wortlaut ab.

Beweist eine erfolgreiche INFO-Antwort die Menüauswahl? Beobachten Sie das Anwendungsergebnis getrennt. Die Annahme einer Nachricht und die Ausführung der gewünschten Menüregel sind unterschiedliche Abnahmebedingungen.

Sollten alle Verfahren gleichzeitig aktiviert werden? Definieren Sie zuerst den unterstützten Pfad und den Umgang mit möglichen Doppeleingaben. Treffen mehrere Darstellungen ein, sollte der Entwurf festlegen, welchen logischen Eingang die Anwendung akzeptiert.