Posts by Don

    Hallo zusammen,


    habe gerade auch einige Rückmeldungen mit diesem Phänomen bekommen. Nach Meetings in Teams bleibt der Audiostream offen und das Headset reagiert nicht mehr bei dem Versuch der Rufannahme.

    Nachdem Teams und der STARFACE-Client beendet und der Client wieder gestartet wurde funktioniert es bei uns auch wieder.


    Ebenfalls Jabra Pro 930

    STARFACE noch auf 6.7.3 sowie der passende Client.


    Scheint wirklich mit MS Teams zusammenzuhängen.


    Viele Grüße

    Don

    Geht auch, dann brauchst du aber wieder eine Gateway zwischen STARFACE und Fritzbox (Patton). FritzBox -> Patton und dann per Netzwerk in die STARFACE einbinden. War bei meinen Fällen aber nie praktikabel. Hier in der Firma hatten wir das allerdings bis vor dem Umstieg vom ISDN-PMX zu rein SIP.


    Bezüglich der Zugangsdaten: Früher war es so das Kabel Deutschland, Unity, etc. immer dir den Router gestellt hatten. Darum hast du auch nie Zugangsdaten bekommen. Jetzt ist der Routerzwang ja abgeschafft worden. Sprich wenn du deinen eigenen Router an den Anschluss hängst, müsstest du eigentlich auch die Zugangsdaten für die Telefonie bekommen. Ob du die dann in der FritzBox einträgst oder in der STARFACE dürfte egal sein. Außer der Provider sagt hier: "Nö, wir lassen die Registrierung nur von dem Gerät mit der und der MAC-Adresse zu..."

    Moin,


    mit einer Appliance (nicht VM) ist das möglich. Hab ich auch zweimal so verbaut. Die FritzBox muss halt noch einen ISDN-Anschluss haben sowie die Appliance. Dann einfach FritzBox-ISDN <-> STARFACE verbinden. Im Admincenter der STARFACE unter "Leitungen" --> "Leitungen" eine neue Leitung anlegen (Name vergeben) und den Port auswählen an dem die FritzBox verbunden ist. Anschließend noch die Rufnummern in der neuen Leitung unter "Rufnummern" eintragen.


    Ich meine an der FritzBox so musst du nichts umstellen. Wenn dann maximal das er die Anrufe einfach weiter reicht zur ISDN-Schnittstelle (S0)


    So ist es jedenfalls bei der Version 6.7


    Gruß

    Don

    Sorry für den Doppelpost:


    Läuft jetzt seit 3 Wochen stabil mit der oben genannten Konstellation an zwei Standorten.


    Gruß

    Don

    Hallo zusammen,


    ich hab jetzt einen von drei Standorten erfolgreich auf FW: 116 mit SF: 6.7.3.20 am laufen. Update über die Hidden Firmware Update Page.

    Folgende Geräte habe ich dort, welche aktuell ohne Probleme funktionieren:


    • SL800H Pro
    • SL750H Pro
    • S650H Pro
    • SL400H


    Unser Hauptstandort folgt dann am Wochenende. Auf FW117 werde ich wohl nicht gehen da es für uns nicht relevant ist und wir nur die Unterstützung für die neuen Mobilteile wie SL800H Pro benötigen.


    Werde dann nächste Woche nochmal berichten.


    Viele Grüße

    Don

    Hallo zusammen,


    sehr gut. Freut mich zu hören.


    Bei uns funktioniert nun auch wieder alles. Unser Dienstleister hatte beim deaktivieren des ALGs doch nicht alles "deaktiviert"... Lange Fehlersuche obwohl das eins der Hauptthemen war zum Tausch der Firewall. Naja.


    Sollt wer Probleme haben bezüglich Fortigate und RTP haben, gerne melden ich glaube ich hab jetzt alle "Szenarien" durch. Ansonsten sollte es damit schon klappen:


    Disable the SIP ALG/Session Helper on the Fortigate – Tech Blog


    Gruß

    Hallo zusammen,


    zufälligerweise stehe ich gerade auch vor dem absolut gleichen Problem.

    App und UCC-Client extern funktionieren nur die Yealink-Telefone machen Probleme. Registrierung, Tasten & Rufsignalisierung funktioniert. Sprache funktioniert nicht. Per Mitschnitt höre ich den externen Teilnehmer. Also 1:1 das Gleiche.


    KingArtus - welche Firewall habt ihr denn im Einsatz? Zufällig eine Fortigate?

    Das Problem liegt zu 90% an der Firewall. Unsere ehemalige Checkpoint die wir vor 2 Wochen rausgeworfen haben, hat die Probleme nicht verursacht. Die neue Firewall ist ebenfalls genauso konfiguriert wie die alte Checkpoint + SIP ALG deaktiviert.


    Aus Testzwecken betreibe ich das Yealink hinter einem WLAN-Router von Vodafone. Als ich mir heute morgen den TCP Dump des Yealinks angeschaut hatte war dort bei gewissen Paketen eine private Adresse vorhanden "10.58.44.151". Welche von unserer Firewall tatsächlich auch geblockt wurde als Destination mit Highports. Ich denke diese kommt von der IPv4-Shared-Adressen (Carrier). Allerdings auch fraglich ob das Probleme macht beim NAT und die Firewall damit dann nicht mehr korrekt umgehen kann bei gefühltem tripple NAT.


    192.168.116.103 interne IP des Telefons

    Zensierte Adresse: unserer öffentliche IP-Adresse für die Telefonanlage

    10.58.44.151: private Adresse (Vodafone?!)


    SIP_Options_Paket.png


    Einige Pakete nach dem obigen kommt ein Status: 200 OK (OPTIONS) gefolgt von einem NOTIFY sip:YEALINK-TELEFON@192.168.116.103:5060. Nach Beendigung des Telefonates (nach dem BYE) - Ebenfalls zwei NOTIFY sip:YEALINK-TELEFON@192.168.116.103:5060


    Ich hab die 10.58.44.151 dann auch mal in der Firewall freigegeben, klar die Pakete werden nicht mehr blockiert, ändert aber auch nichts an dem Verhalten. Ist und bleibt halt auch einfach eine private Adresse die eigentlich auch nicht routebar sein sollte?!


    Evtl. kann damit jemand etwas mehr anfangen. Wir warten gerade noch auf einen Termin mit unserem Systemhaus bezüglich der Problematik.


    Wenn sich etwas neues bei uns ergibt gebe ich hier Rückmeldung.


    Gruß

    Don

    Moin,


    unter Admin -> Erweiterte Einstellungen -> Wartemusik -> auf den "Edit"-Stift auf der rechten Seite -> Musik -> hier die jeweiligen Lautsprecher anklicken. Entweder lauter oder leiser.
    Oben kannst du dann ein Endgerät wählen mit welchem du es dir anhören kannst.


    Gruß
    Don

    Hallo zusammen,


    erstmal wünsche ich euch noch ein frohes neues Jahr. Ich hoffe ihr seid alle gut reingekommen!



    Vielleicht hat von euch jemand schon mal ein ähnliches Projekt abgebildet und kann seine Erfahrungen teilen.


    Ich würde gerne eine bestehende TK-Anlage (Auerswald) gegen eine SF Compact tauschen. Der aktuelle Stand ist so wie ich ihn auch gerne an der SF hätte:



    Vodafone --> Fritzbox per ISDN/S0 --> Auerswald



    Sprich die Fritzbox reicht das Signal wohl einfach nur durch. Solche Setups habe ich nun schon häufiger gesehen und diese funktionieren auch erstmal ohne Probleme.


    Nun zu meiner Frage, ist es mit der SF Compact genauso "einfach"?



    Vodafone --> Fritzbox per ISDN/S0 --> SF Compact ISDN



    Falls ja, gibt es für die Konfiguration der SF etwas zu beachten?


    Der Umzug der Rufnummern zu einem SIP-Provider ist momentan leider keine Option.
    Die Fritzbox wird zum Ende des Projektes auch nur noch die Einwahl ins Internet (kein WLan, DECT, DHCP, etc.) übernehmen. Die Fritzbox wird allerdings nicht in den Bridge-Mode geschaltet und soll eben die Anrufe an die SF "durchreichen".


    Falls jemand Tipps hat, lasst sie mich gerne hören.
    Meiner Meinung nach sollte es eigentlich funktionieren die Fritzbox direkt an die SF zu hängen, aber ich lasse mich da gerne eines besseren belehren :)


    Solltet ihr noch Fragen haben beantworte ich euch diese natürlich.



    Danke im Voraus.


    Gruß
    Don

    Ich denke STARFACE geht davon aus wenn du ein Smartphone hast und dort die App laufen hast, dieses auch immer "an" ist.
    Somit würdest du auf dein Smartphone das Telefonat bekommen. So wie wenn dich jemand in Skype anruft.


    Wobei ich dann dieses Verhalten mir nicht erklären kann:


    Quote

    Android App starten und dort Telefonie und Chat deaktivieren -- > BLF bleibt grün


    Hast du danach mal versucht dich anrufen zu lassen was dann passiert?


    Gruß
    Don

    Hi,


    sobald du ein aktives Telefongeräte hast (in der Administration) bleibt das BLF grün. Grün sagt aus dass du eben an einem Telefon angemeldet bist. Sobald du an allen Telefonen abgemeldet bist bzw. deinem Benutzer keine Geräte mehr zugeordnet sind wird die BLF grau mit einem weißen Strich.


    Theoretisch sollte deine Android-App dann "pushen" wenn du einen Anruf bekommst.


    Gruß
    Don

    Kurze Rückmeldung und sorry für den Doppelpost.


    Wir haben das Problem nun selbst behoben. Es lag an unserer Firewall (Checkpoint).


    Es gibt dort in den Services einen "Virtual Session Timeout" der per default auf 40 Sekunden steht... Dieser hat wohl dafür gesorgt das die oben beschriebenen Unlinks/Links zustande kommen.
    Wir haben nun in allen RTP-Services den Timer auf 1 Stunde gestellt danach sind die Probleme nicht mehr aufgetreten.


    VST.jpg


    Vielleicht hilft das dem ein oder anderen irgendwann mal.


    Was mich etwas wundert ist das die gleichen Services auch schon seit zwei Jahren im Anlagenverbund benutzt werden und es hier keine Probleme gab.



    Gruß
    Don

    Guten Morgen,


    tut mir leid das ich das Thema nochmal hochholen muss.



    Wir haben letzte Woche ebenfalls auf DeutschlandLAN SIP-Trunk umgestellt und haben genau das gleiche Phänomen wie oben beschrieben, dass im Supportlog immer mal wieder die Telefone "unlinked" und wieder "linked" werden...



    Sobald das passiert kann es sein plötzlich beide Seiten nichts mehr hören und nach einem kurzem Momenten hören sich die beiden wieder. Allerdings kam es auch schon vor das aus dem "kurzem Moment" fast eine Minute wurde...


    Sprich das Gespräch als solches bleibt bestehen nur wird durch den "Unlink" des Telefones das Audio unterbrochen und beide Seiten denken das Gespräch sei "weg".


    @32Goj_Base2 weißt du zufällig noch wie du das Problem beheben konntest?



    Konstellation sieht bei uns ähnlich aus:


    LANCOM R884VA (Bridged!) --> Checkpoint Firewall --> Starface Compact alle Ports sind soweit auch freigegeben wie auch im Anlagenverbund da funktioniert soweit auch alles ohne Probleme. Den Fehlerleitfaden hab ich soweit auch schon durchgestielt bis auf Punkt 4 (Umstellung von TLS auf TCP) da sind dann gar keine Telefonate mehr möglich.


    Leider ist das alles etwas undefinierbar wann es genau passiert, es kann nach 30 Sekunden oder aber auch erst nach 3 Minuten passieren.


    Vorab schon mal danke!


    Gruß
    Don

    Kann mir jemand Feedback dazu geben, wie stark die Umleitungscheckboxen im UCC Client verwendet werden?
    Unbenannt.png


    Ich glaube wenn man sich eine Taste auf dem Telefon programmiert hat dann eher selten. Sind viele (zu mindestens hier aus der Firma) von früher gewohnt die Taste am Telefon zu verwenden.


    Die meisten werden sich, wie schon öfters geschrieben, wünschen das man mehrere Umleitungstasten hat sprich:


    • Umleitung zu Zentrale 10 --> Alle Rufnummern (intern/extern) werden auf die vordefinierte Nummer umgeleitet
    • Umleitung zu Handy +49170123456 --> Alle Rufnummern (intern/extern) werden auf die vordefinierte Nummer umgeleitet


    Sofern ich diese Taste dann nochmals drücke sollten auch beide Umleitungen (intern/extern) wieder deaktiviert werden.


    Umfrage hab ich auch mal ausgefüllt.


    Grüße