Posts by Ralf68

    Also ich kann kein grundsätzliches Problem bestätigen. Ich habe IVR hinter Connect ohne dezidierte IP eingerichtet und egal über welchen Provider ich anrufe - es tut.

    Es muss sich - aus welchen Gründen auch immer - um einen Einzelfall handeln.

    Wurde versucht eine andere Nummer vor das IVR zu schalten? Sind andere Module im Spiel? Wie ist/war die Auslastung der Cloud?

    Nochmal Herzlichen Dank an die viele Unterstützung.

    Aktuell haben wir die Audio Aufnahme beim Kunden neu Konvertiert in Wave 08 kHz 16 Bit und dies neu Hochgeladen.

    Dies hat etwas Verbesserung gebracht, aber noch keine endgültige Lösung.


    Die IVR Modul-Anpassungen haben leider auch nicht den gewünschten Erfolg gebracht.

    Wir gehen dies weiter mit dem Kunden durch und werden euch hier weiter auf den laufenden Halten.

    ist es denn auch Mono? Wurde geprüft, ob das aufgenommene Audio das Problem ist? Vielleicht ist da ja ein Fehler in der Codierung, z.B. es ist falsch komprimiert.

    Ich finde ja, mein Song ist es wert auch von extern gehört zu werden ;)

    Quote


    Also iFMC war Schuld an der Ansage. Da ja die Anlage einen externen Ruf auf baut.

    Genau, das läßt sich also nicht technisch vermeiden.

    Wie bekomme ich denn mit, welche Cloudanlage offline ist, wenn ich es nicht darauf ankommen lassen möchte, dass ein wutenbranter Kunde anruft ?

    Reicht ein einfacher Ping ? Oder sieht man es in der Cloud verwaltung ?


    Oder habt ihr euch Checkscripte geschrieben, die automatisiert per API checken, ob die Anlagen da sind ?

    einfach die Weboberfläche aufrufen. Ping ginge nur bei dedizierten Clouds. Aber ist gleich alles gefixt.

    Technischer Kommentar nichts offizielles - aktueller Stand scheint/ist nur eine Node betroffen. Diese tut zwar seit Stunden wieder, aber vereinzelt sind Clouds nicht hoch gekommen. Wir starten diese Clouds jetzt nach manueller Prüfung von Hand neu. Läuft gerade und sollte in maximal 30 Minuten komplett erledigt sein. Mehr dazu dann erst morgen.

    @Starface Crew - Es würde uns als Dienstleister und Ansprechpartner für unsere Starface Endkunden sehr helfen, wenn ihr mehr kommuniziert. Wir alle hören vermutlich das gleiche...schon wieder... wie lange ungefähr...nie wieder Starface...an was liegt es. Auf der Status Seite wird auch nur auf das Forum verwiesen. NACHDEM diese Störung behoben wurde, würde mich als schon interessieren was EUER VORDIENSTLEISTER bereits alles unternommen hat bis heute. Ist leider nicht das erste mal. Aktuell bekommen die Starface Endkunden zu viele negative Nachrichten - laufende Störungen, Preiserhöhung.
    Hoffe die GL der Starface ist sich diesem Umstand bewusst.

    Wir erzählen unseren Kunden nun seit einigen Wochen/Monaten das es besser wird und die Starface dran ist.
    Unsere Kunden wollen da aber nicht mehr all zu lange zuschauen.

    Bitte liebe GL von Starface - teilt eure Schritte und Verbesserungen mit eurem Vordienstleitern und Rechenzentren mit den Partnern.

    ich würde vermuten es ist ein Routing/Switching Problem, evtl. was an der Glasfaser. Wir bekommen vom Vordienstleister leider (noch) keine genauen Informationen. Unsere GL ist im übrigen trotz Urlaub an der Lösung beteiligt. Dementsprechend groß ist auch der Unmut in Richtung Vordienstleister ...

    ok, danke. Das ist eine wichtige Information. Die gebe ich weiter. NetCup hatte auch eine angekündigte Netzwerk-Wartung gestern von 22-23 Uhr. Das scheint es nicht besser gemacht zu haben.


    Kunden die eine Selbstgehostetet VM der STARFACE bei NetCub haben, die Server stehen aber in Wien, haben das selbe Problem.

    Noch Frage dazu - nutzen die Connect, oder auch einen anderen Trunk?

    Wir haben Provisionierungs-Probleme. 20% aller Yealink Telefone wollen sich nicht registrieren. Die anderen laufen einwandfrei!
    Der Windows UCC Client geht mit allen Accounts / Teilnehmern einwandfrei. Alles sehr komisch!

    Vielleicht hat (auch) der Yealink Server Probleme mit der Erreichbarkeit?!

    Wir haben Verbindungen zu vielen Servern/Providern, auch im Ausland. Colt ist ein wichtiger, aber nicht der einzige. Fällt z.B. Colt aus oder reagiert nicht, geht das über einen anderen Provider raus. (Und natürlich anders herum)

    Hi,


    dieser MTR ist in Ordnung. Du meinst sicherlich die Zeile

    | 100ge0-79.core2.ams1.he.net - 60 | 20 | 8 | 8 | 95 | 303 | 303 |

    Die großen Maschinen sind so konfiguriert, dass sie ICMP keine Priorität einräumen. Da kann es durchaus zu diesen Werten kommen.

    Wichtig ist

    | www.MEINWEBSERVER .de - 0 | 68 | 68 | 16 | 16 | 17 | 16 |

    Da ist dann alles in Ordnung.

    Abgesehen davon - für RTP Analyse ist der Schalter --udp zu setzen. Hatte ich gestern vergessen zu erwähnen.

    Geb ich dir vollkommen Recht.
    Hier muss ein offzielles Statement von der GF her.

    Und wir wollen die genaue Ursache wissen und wie Starface in Zukunft solche Ausfälle schneller bearbeitet.
    (Wir wissen alle wie komplex das ist...)

    Auch Statusmeldungen müssen schneller kommen. Vllt. dann in einem extra Thread in dem keiner flamed.

    Immerhin hat sich mal der GF vom Vordienstleister auch die Nacht um die Ohren geschlagen.