Sprachübertragung teilweise nur einseitig

  • Wenn ich mir das IVR Modul so ansehe ist es an sich ganz simpel gestrickt, das einzige, was mir gegenüber anderen Modulen auffällt, ist dass nicht explizit ein "Answer" ausgeführt wird, sondern direkt ein PlaybackResourceFile ausgelöst wird.


    Meinard Welche STARFACE Version hast du aktuell?


    MFG

    Fabian

  • Könnte das bei manchen Anrufern dazu führen, dass das System des Anrufers auf ein "Answer" wartet?


    Uns ist vor 3 Wochen in etwa erst aufgefallen, dass das IVR Ursache dafür ist, dass Sprache ab und zu nur einseitig übertragen wird. Wir sind davor von allem möglichen ausgegangen, bis ein Anrufer berichtet hat, dass er die Ansage zur Auswahl der Ziffern, sprich die IVR Ansage, nie gehört hat. Da sind wir erst drauf gekommen dass sobald die Sprache einseitig übertragen wird immer der Anruf auf das IVR einging und grundsätzlich nie die Ansage für den Anrufer abgespielt wurde.


    Aktuell haben wir die 8.0.0.11 installiert. Wir hatten das Problem aber schon bei Version 7.x und allen Zwischenversionen, also dass die Sprache nur einseitig übertragen wird. Mit der aktuell 8.0.0.11 sind wir drauf gekommen, dass es am IVR liegen muss, da nicht mal die Ansage abgespielt wird.

  • wenn das Modul kein answer macht, kann unter Umständen das transcoding möglicherweise nicht greifen und man hat genau dieses Fehlerbild


    Von Zeit zu Zeit kommt es vor, dass obwohl eine aktive Sprachverbindung besteht, ein Gesprächspartner den anderen nicht – oder nicht mehr hören kann.

    Dieses Verhalten bezeichnet man als “one way speech”. Eine Verbindung in welcher nur in eine Richtung gehört bzw. gesprochen werden kann. Dieses tritt meistens dann auf, wenn bei der Codec-Aushandlung zwei verschiedenartige Codecs aufeinandertreffen.

    Beispiel 1: Ein eingehender Anruf verwendet den Codec G.711 a-Law, das Endgerät nimmt diesen jedoch mit G.722 entgegen.

    Beispiel 2: Ein eingehender Anruf mit Codec G.711 a-Law, die Anlage nimmt einem Ansagetext auch mit G.711 a-Law an. Im folgenden wird der Ruf weitergeleitet oder vermittelt und das Zieltelefon verwendet einen anderen Codec.

    Beispiel 3: Während eines Gesprächs mit erfolgreicher Codecaushandlung kommt es zu einem Reinvite, nach welchem sich die beteiligten Geräte nicht mehr einigen.


    ich ganz unbescheiden nehme an, hätte man ein Modul , welches erst ein "normales" Gespräch aufbaut , hätte man das Problem vielleicht nicht mehr.


    Transcoding – Transcoding vermeiden

    Transcoding bei VoIP Verbindungen, bezeichnet die Wandlung und Aushandlung der am Gesprächsaufbau beteiligten Audio Codecs zwischen den beteiligten Geräten.

    Beispiel: bei einem VoIP Gespräch über ein TK-System wird nach extern der Codec G.711 verwendet, intern zu den IP-Telefonen jedoch der Codec G.722.

    So ist das TK-System z.B. eine be.IP oder eine Hybird gezwungen, eine Anpassung durchführen.

    Gleich zu Beginn eines VoIP Gesprächs erfolgt die Aushandlung des zu verwendenden Sprachcodecs.

    Hierbei stehen üblicherweise ganze eine ganze Reihe unterschiedlicher Codecs zur Verfügung z.B. G.711A-Law, G.711µ-Law und die komprimierenden Codecs G.722 und G.726.

    Je mehr Wandlungsstufen – und je größer die Auswahl an zur Verfügung stehenden Sprachcodecs wird, desto träger und fehleranfälliger wird die Aushandlung der Akustik, bevor die Gesprächsverbindung besteht.

    Um das Verhalten ‘Transcoding’ für alle am Gesprächsaufbau beteiligten Geräte und Vermittlungsstellen zu vereinfachen, wird empfohlen, ausschließlich den Codec G.711 A-LAW im Codecprofil zu verwenden. Dieser wird praktisch von allen Netzbetreibern und Endgeräten unterstützt. Es ist der Codec, welcher bereits seit Jahrzehnten im ISDN-Protokoll Verwendung findet. (r) Bintec-elmeg


  • Erstmal vielen Dank für deine ausführliche Antwort.


    Wie ist denn das Verhalten, wenn ich vor das IVR eine Gruppe schalte und ich die externe Gruppenrufnummer dann an eine Rufnummer weiterleite, die dem IVR zugeordnet ist? Nimmt die Gruppe das Gespräch kurz an oder wie verhält sich da der Rufaufbau?


    d. h. Anrufer -> Gruppe mit sofortiger Weiterleitung -> IVR ?

  • so gut kenne ich tatsächlich das Innenleben der SF noch nicht, um das beantworten zu können.

    Wichtig ist, das der Codec sauber ausgehandelt wird; vielleicht auch noch mal in den Einstellungen des Providers prüfen, was da so steht.

    Da du mittlerweile ja einen nachstellaren Weg gefunden hast, würde ich das mit try und error machen.

    • Official Post

    Hallo Meinard,


    ich habe mir das Ticket angesehen und auch mit den beteiligten Kollegen gesprochen. Es ist aktuell so, dass seitens der Anlage sowohl bei Positiv- als auch Negativ-Beispielen RTP-Streams gesendet werden und die TCP-Dumps im Prinzip auch identisch sind, was den Inhalt der SIP-Felder angeht. Von der Perspektive her sollte auf jeden Fall Audio beim Anrufer ankommen.


    Da der Fehler wohl in bestimmten Fällen reproduzierbar ist, hat der bearbeitende Kollege angeboten, nochmal einen Live-Test gemeinsam mit dem Vordienstleister von STARFACE Connect durchzuführen um zu prüfen, ob auch dort RTP-Streams ankommen und somit unsere Infrastruktur sauber verlassen.


    Ich würde empfehlen, diese Chance auf jeden Fall wahrzunehmen und den Test durchzuführen.


    Die Kollegen sind aktuell auch nochmal am Ticket dran und melden sich zeitnah bei dir (per E-Mail und telefonisch).

  • Hallo Daniel,


    die Streams werden auf jeden Fall ankommen- sie sind nur nicht hörbar weil falscher Codec.....
    es kommt ja hörbar im Dump an.


    ich würde die Kette einmal auf alaw runterstufen . dann sollten keine Probleme auftreten.

  • Hallo Daniel Mauritz ,


    der Fehler ist IMMER reproduzierbar, sobald das IVR das Gespräch annimmt. Warum können wir nicht die Aushandlung der Codecs verfolgen? Die Meinung der anderen Kollegen von FabianZ oder Scaramu halte ich für äußerst möglich, dass es ein Codec (Aushandlungs)problem ist.

    Warum sollen wir dann wieder auf Dumps setzen? Wir haben doch schon gesehen, dass hier alles passt. Warum sollte nun bei einem Live-Test ein anderes Ergebnis raus kommen? Wir können doch eindeutig beweisen, dass es am IVR Modul liegt?

    Interessant wäre auch die Frage warum das IVR Modul das genannte "Answer" nicht sendet?

  • Hallo Daniel,


    die Streams werden auf jeden Fall ankommen- sie sind nur nicht hörbar weil falscher Codec.....
    es kommt ja hörbar im Dump an.


    ich würde die Kette einmal auf alaw runterstufen . dann sollten keine Probleme auftreten.

    Wo können wir das anpassen? Ich kenne nur die Einstellung im Provider (Leitung) und im Telefon selbst. Aber wo stelle ich ein, welchen Codec die Anlage selbst verwendet, demnach auch Module?

    Finde es etwas Schade, dass der Starfce Support dauernd auf den Dumps rum reitet, dabei haben wir doch schon bewiesen dass RTP fliest und im Dump alles zu hören ist. Ich verstehe nicht, warum nicht der Ansatz mit den Codecs bzw. der Aushandlung verfolgt wird oder warum das IVR Modul kein answer macht.

  • Hallo Meinhard,

    ich bin ja nun auch erst auf die Idee der Codecs gekommen, wegen Fabians Aussage, das kein 'echter' <answer> gesendet wird.
    ich kann mir das mal auf Asterisk Ebene anschauen, wann der Codes ausgehandelt wird, vermute aber eben, das erst ein <answer> vorliegen muss.
    das weiss Fabian sicher besser.


    Lanze für Daniel:
    ich würde den Test dennoch mitmachen, damit alles sauber dokumentiert ist. Ein dump mehr schadet nicht :)

  • Lanze für Daniel:
    ich würde den Test dennoch mitmachen, damit alles sauber dokumentiert ist. Ein dump mehr schadet nicht :)

    Wir würden den gerne mit machen, allerdings sind wir dann auf den Kunden (Anrufer) unseres Kunden angewiesen. Heute hat uns unser Kunde mitgeteilt, dass er nicht möchte, dass wir weitere Live-Tests mit seinen Kunden machen. Daher wäre mir eine proaktive Lösung lieber. Wir haben das Problem nun seit 4 Monaten und sitzen mittlerweile auf Kohlen. Unser Kunde ist extrem genervt und die Situation ist kurz vor der Eskalation.


    Daher ist mir eine proaktive Lösung lieber, die ganzen Dumps der letzten Monate haben ja kein Stück geholfen. Jetzt mit dem Codec und dem IVR Modul haben wir eine heiße Spur (aus meiner Sicht). Nun fehlt mir allerdings die Tiefe für das Verständnis des Starface Systems um den Punkt zu finden, wo letztendlich das Problem liegt - wie z. B., dass das Modul kein Answer macht.

  • Richtig, und der ankommende Anruf Codec sollte dann auch alaw sein

    In der SF Connect Leitung ist alles ausgegraut, d.h. dort können wir wie bei Leitungen, wo ich Zugangsdaten manuell eingebe, keinen Codec ändern. Ich kann es nur in den Telefonen ändern, allerdings nimmt ja im Fall des IVR Moduls die Anlage selbst das Gespräch an.

  • In der SF Connect Leitung ist alles ausgegraut, d.h. dort können wir wie bei Leitungen, wo ich Zugangsdaten manuell eingebe, keinen Codec ändern

    Tatsächlich - ich sehe es gerade - das ist dann SF Aufgabe da vielleicht den Codec editierbar zu machen

    Aber nochmal zur Klarstellung:


    wenn du alles auf alaw stellen kannst und das dann funktioniert, weisst du lediglich, das es das transcoding ist, behoben ist es damit nicht.

    • Official Post

    Hallo Meinard,


    der Fehler ist IMMER reproduzierbar, sobald das IVR das Gespräch annimmt.

    Bei den Tests haben die Kollegen von verschiedenen Providern (Connect, Vodafone und O2) auf der Leitung angerufen und konnten die Ansage des IVR hören. Soweit ich das aus dem Ticket herausgelesen haben, waren es "nur" ca. 8% der Telefonate die auf den Fehler gelaufen sind.


    Also muss es auch ein Stück weit mit dem Anrufer (Anlage, Provider, Carrier, etc.) selbst zu tun haben.


    Finde es etwas Schade, dass der Starfce Support dauernd auf den Dumps rum reitet, dabei haben wir doch schon bewiesen dass RTP fliest und im Dump alles zu hören ist.

    Mit einem Dump seitens der Anlage prüfen wir natürlich im ersten Schritt, ob die Anlage alles richtig macht. Das scheint hier der Fall zu sein.


    Ich verstehe nicht, warum nicht der Ansatz mit den Codecs bzw. der Aushandlung verfolgt wird

    Das prüfen wir gerade.


    oder warum das IVR Modul kein answer macht.

    Bei einem PlaybackResourceFile wird auch ein Answer ausgeführt.


    Wir werden den Fall Stück für Stück analysieren, dabei gerne auch unseren Vordienstleister bei einem Test mit involvieren. Es kann aber auch durchaus darauf hinaus laufen, dass der Fehler nicht auf der Seite von STARFACE oder STARFACE Connect liegt, sondern an irgendeiner Stelle auf dem Weg von der PBX zum Anrufer, die außerhalb unseres Einflusses liegt.


    Ich bin mir der Tatsache bewusst, dass diese Antwort die frustrierendste aller Möglichkeiten ist, aber damit wären zumindest einige Komponenten ausgeschlossen und man kann die restlichen prüfen.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!