Kein Ton - Ausgehender Ruf via SIP an eine Zentrale okay, nach Weiterleitung kein Ton

  • Hallo,


    folgendes Szeanrio: ausgehender Anruf von einem SIP-Telefon über die Starface an externe Nummer
    Verbindungsaufbau okay, Telefonat okay.
    Sobald der Angerufene (Gegenstelle) allerdings den Anruf bei sich intern weiterleitet, ist der Ton weg (in beide Richtungen). Das Gespräch an sich ist aber noch aktiv.


    Bei der Recherche im Internet bin ich auf die Aktivierung "activating "fax detection - sip" on the inbound route for the called DID" gestossen. Ich finde die entsprechende Option bzw. Datei in Starface aber nicht
    (vgl.: https://community.freepbx.org/…ll-to-ext-number/29367/13).


    vielen Dank vor ab

  • Bin hier per Zufall drauf gestoßen. Wir konnten ähnliches auch beobachten: Eingehender Anruf kommt rein, Kollegin nimmt entgegen und spricht, alles OK. Dann kommt Weiterleitung an einen anderen internen Kollegen und keiner hört sich mehr.

  • Danke schon mal für die schnelle Rückmeldung.


    @woestmar: bei uns ist das genau andersherum. Wir rufen bei einem Kunden an, und dort leitet die Zentrale das von uns initiierte Gespräch weiter.


    Das das ein Problem der Gegenstelle sein müsste, habe ich auch erst vermutet. Ich habe deshalb das gleiche Szenario mit meinem Mobiltelefon ausprobiert. Wenn ich also von dem Handy den gleichen Kunden anrufe und dann "weiterverbunden" werde, kann man sich weiterhin verständigen. Von daher muss es irgendwie an der Starface liegen.


    Neuste Updates der Starface sind drauf, auch die ganzen Portweiterleitungen habe ich nochmals kontrolliert und müssten korrekt sein


    Interessanterweise funktioniert das gleiche Szenario bei einem anderen Kunden, den ich ebenfalls angerufen habe. ggf. tritt das Problem auch nur auf, wenn 2 SIP-Leitungen beteiligt sind.


  • Das das ein Problem der Gegenstelle sein müsste, habe ich auch erst vermutet. Ich habe deshalb das gleiche Szenario mit meinem Mobiltelefon ausprobiert. Wenn ich also von dem Handy den gleichen Kunden anrufe und dann "weiterverbunden" werde, kann man sich weiterhin verständigen. Von daher muss es irgendwie an der Starface liegen.


    Nicht wenn ihr eine durchgängige SIP-Verbindung habt.
    Der korrekte Test wäre, einen anderen (nicht-SIP-) Kunden anzurufen und diesen eine Weiterleitung machen zu lassen.



    Interessanterweise funktioniert das gleiche Szenario bei einem anderen Kunden, den ich ebenfalls angerufen habe. ggf. tritt das Problem auch nur auf, wenn 2 SIP-Leitungen beteiligt sind.


    Aha... Ich tippe immer noch darauf, dass der erste Kunde versucht, die RTP-Streams umzubiegen.

  • Das Problem besteht weiterhin. Ggf. helfen Packettraces weiter


    Beide Traces sind auf der Firewall vor der Starface mitgeschnitten worden.


    Nummer 1: Kunde, bei dem das Audio nach der Weiterleitung "weg ist" - interessante Stellen sind mit einem ?? markiert (Warum wird zwischendurch ein weiterer RTP-Stream aufgemacht eingeheneder und ausgehnder Port jeweils +1 ?)
    Später dann kommen keine Antwortpakete mehr, aber die Starface scickt weiter fröfhlich Pakete.


    Nummer 2: Kunde, bei dem die Weiterleitung funktioniert - sieht eigentlich ähnlich aus, auch der zweite RTP-Stream mit UDP-Port +1 taucht da auf - wie gesagt, funktioniert aber.

  • Leider ist nicht sehr viel herauszulesen. Es fehlen informationen über die verwendeten Codecs und den Inhalt der SIP-Pakete.


    Vielleicht kommt es nämlich auch zu einer Codec-Neuaushandlung, die schief geht?!
    Das passiert manchmal, wenn eine Seite z.B. "alaw,ulaw" anbietet und die andere Seite "ulaw,alaw" (man beachte die Reihenfolge).


    Welche Codecs sind in der Providerkonfiguration eingetragen? Ich würde dort ulaw mal entfernen.

  • Danke für ihre Mühe weiterhin.


    In der Providerkonfiguration habe ich geschaut. Neben g722 waren noch ulaw und alow aktiv. Wir haben jetzt das Profil in allen Kombinationen durchgetestet, also jeweils ulaw,alaw und g722 als jeweils einzig erlaubter Codec. Leider weiterhin ohne Erfolg. Wir haben auch auch schon einen anderen SIP-Provider testen können. Damit haben wir aber das gleiche Problem.


    Die Frage bzgl. UDP-Port+1 scheint sich zumindest erledigt zu haben. Das ist anscheinend nur ein Kontrollport, der zu dem eigentlichen RTP-Stream gehört. Zuerst hatte ich vermutet, das das die Pakete wären, die beim "Weiterleiten" neu generiert würden. Das scheint aber nicht der Fall zu sein.

  • Ja, zumindest kann ich das für den gegenüberliegenden Teilnehmer bestätigen, mit dem wir testen. T- Octopus Open Basiseinheit 830 mit ner Erweiterung, wo ein Aufkleber OmniPCX Office dranklebt. Die Alcatel hängt an einem ISDN-Multiplex-Anschluss, hat aber auch einige SIP-Provider eingerichtet. Unsere Tests gehen aber defenitiv über den Multiplex-ISDN-Anschluß rein. Das wurde mit dem Dienstleister der TK-Anlage überprüft

  • Du hattest weiter oben geschrieben, dass das Problem nur auftritt, wenn durchgängig SIP im Einsatz ist und dass es bei einem anderen Test-Teilnehmer funktioniert.
    Da die OmniPCX unter Umständen eine direkte Kommunikation zwischen den Endgeräten versucht, klingt es für mich nach einem Problem beim OmniPCX-Teilnehmer.


    Eine Weiterleitung beim anderen Teilnehmer sollte für den Anrufer ohnehin in jedem Fall transparent sein (es sei denn, es wird verschlüsselt und dadurch eine Key-Renegotiation oder ein Re-INVITE getriggert).
    Ich wüßte also nicht, wie die STARFACE in diesem Szenario verantwortlich sein sollte.

  • Ich kann mir das auch nicht wirklich erklären, warum die Starface da eine Rolle spielt. Ich bei meinem ersten Posting auch noch davon ausgegangen, das sich das Problem (wenn überhaupt) nur bei VOIP-Testteilnehmern und nicht via ISDN "zeigen" würde und als Ursache nur so etwas wie RE-Invite, usw. bei dem "angerufenen" Anschluss in Frage kommen kann.


    Fakt ist leider, das bei unserem Test-Teilnehmer (aber eben auch bei anderen) das Phänomen zu beobachten ist. Und auch nur dann, wenn die Strafce bei dem Test-Teilnehmer anruft und dort vermittelt wird. In der Gegenrichtung, also Verbindungsaufbau vom Testteilnehmer zur Starface und dann Vermittlung beim Testteilnehmer bleibt Audio erhalten. Das macht das ganze ja noch komischer.


    Wir haben das Verhalten beim Testteilnehmer mit dessen Alcatel-Dienstleister auch noch weiter runtergbrochen. Es spielt z.B. auch keine Rolle, ob auf der Testteilnehmer-Seite die Vermittlung von einer UP0-Nebenstelle zu UP0, von UP-0 zu IP-Telefon, IP-Telefon zu UP0 oder IP- zu IP-Telefon erfolgt. Nach der Vermittlung ist Audio weg, das Gespräch aber weiterhin offen bis ein Teilnehmer auflegt.


    Edit: Sieht für mich nach diesem Bug aus: https://issues.asterisk.org/jira/browse/ASTERISK-25854


    Edit, die 2.: Tippen mittlerweile auch auf easybell. Anbei 2 Netzwerkmitschnitte auf der Firewall vor der Starface. Interassnterweise kommen im ersten Teil irgendwann keine Pakete mehr von easybell zu uns zurück. Glieche Phänomen allerdings auch bei einem weiteren SIP-Provider


  • Ich kann mir das auch nicht wirklich erklären,...


    Ich verstehe dann nicht, warum Du der Ansicht bist es hätte etwas mit der STARFACE zu tun. Das ist unter Berücksichtigung der vorliegenden Informationen die unwahrscheinlichste aller Quellen.


    Es spielt z.B. auch keine Rolle, ob auf der Testteilnehmer-Seite die Vermittlung von einer UP0-Nebenstelle zu UP0, von UP-0 zu IP-Telefon, IP-Telefon zu UP0 oder IP- zu IP-Telefon erfolgt. Nach der Vermittlung ist Audio weg, das Gespräch aber weiterhin offen bis ein Teilnehmer auflegt.


    Das heißt: Selbst wenn ein Medienbruch stattfindet, ist das Audio weg, wenn der Gegenüberliegende Teilnehmer intern vermittelt?
    Das ist etwas, das die STARFACE nicht einmal mitbekommt. Wie soll sie da die Ursache sein?!



    Edit: Sieht für mich nach diesem Bug aus: https://issues.asterisk.org/jira/browse/ASTERISK-25854


    Tut mir echt leid, aber Du suchst an der falschen Stelle.
    Das hat nichts mit deinem Fall zu tun. Aber mal angenommen, es wäre dein Fall: die betroffenen Versionen aus dem Report sind Asterisk 13.4.0/13.7.2. STARFACE setzt die Version 11.25.1 ein (in STARFACE 6.4.2.x).
    Außerdem betrifft der Report die Kombination aus Asterisk und Cisco-Telefonen.


    Du verzettelst dich hier... das Problem liegt außerhalb deiner Sphäre (beim Gegenüber oder bei den beteiligten Providern). Das ist blöd, weil Du's dann nicht beheben kannst, aber so etwas gibt es.



    Edit, die 2.: Tippen mittlerweile auch auf easybell. Anbei 2 Netzwerkmitschnitte auf der Firewall vor der Starface. Interassnterweise kommen im ersten Teil irgendwann keine Pakete mehr von easybell zu uns zurück. Glieche Phänomen allerdings auch bei einem weiteren SIP-Provider


    Das läßt sich relativ leicht Gegentesten: Man nehme einen anderen SIP-Provider.


    Wenn keine RTP-Pakete vom Gegenüber mehr kommen, ist klar, warum das Audio fehlt. Aber wie um Himmels willen, soll das STARFACE-seitig behoben werden? Soll die STARFACE Audiodaten aus der Luft generieren?

  • Halleluja!


    Problem gelöst. Und es war tatsächlich der SIP-Anbieter bzw. einer seiner Partner-Carrier. Heute hat ein Mitarbeiter unseres SIP-Providers den Carrier gewechselt - und siehe da - es funktioniert alles.


    Danke für die freundliche Unterstützung.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!