Posts by Albeck

    Hi Sternengesichter,


    ich habe mir heute mal die Zeit genommen den Starface Netzwerktraffic in Wireshark mitzuschneiden und bin etwas verwundert.


    1. der UCC Client sendet seine UDP RTP Stream mit DSCP CS7:


    pasted-from-clipboard.png

    CS7 ist laut RFC eigentlich reserviert und weiterhin für Netzwerk "Control" vorgesehen:

    (https://www.rfc-editor.org/rfc/rfc4594#section-1.5.4)

    pasted-from-clipboard.png


    Zwar hat es auf mit CS7 auf einigen Switchen die höchste Prio, auf anderen wird CS7 aber "geblockt"


    Microsoft Teams verwendet EF und das ist laut dem RFC auch für VOIP vorgesehen:
    pasted-from-clipboard.png


    Bei Starface NEON wird überhaupt kein DSCP Tag gesetzt, zumindest in der Desktop App nicht.

    pasted-from-clipboard.png


    Warum hier überhaupt keine DSCP gesetzt wird ist mit unklar.

    MS Teams verwendet hier AF41 (https://docs.microsoft.com/de-de/microsoftteams/qos-in-teams)


    Mit Neon im Webbrowser wird CS5 gesetzt

    pasted-from-clipboard.png


    Das ist zumindest besser und OK.


    Allerdings, dass der Starface UCC CS7 verwendet und NEON überhaupt nichts ist Meinung nach unschön und nicht korrekt.


    Mit einer QoS Policy GPO lässt sich das fixen:

    pasted-from-clipboard.png



    Was sind euere Meinungen dazu?

    Guten Tag,


    in dem Knowledgebase Artikel zur Starface Cloud wird darauf hingewiesen, dass die NAT Tabelle die Eintrage länger als 60 Sekunden halten muss um Verbindungsabbrüche zu vermeiden:


    Fehlerleitfaden - Telefon/Endgerät verliert Verbindung zur STARFACE Cloud - STARFACE WIKI (Deutsch) - STARFACE WIKI


    Leider wird hier kein Bezug auf die Ports oder Protokolle genommen, für die dies zutreffend sein muss.

    Könnte dies genauer spezifiziert werden?


    Mein Router hat folgende conntrack timouts:


    'ip_conntrack_generic_timeout' => 600,

    'ip_conntrack_icmp_timeout' => 30,

    'ip_conntrack_tcp_timeout_close' => 10,

    'ip_conntrack_tcp_timeout_close_wait' => 60,

    'ip_conntrack_tcp_timeout_established' => 86400,

    'ip_conntrack_tcp_timeout_fin_wait' => 120,

    'ip_conntrack_tcp_timeout_last_ack' => 30,

    'ip_conntrack_tcp_timeout_max_retrans' => 300,

    'ip_conntrack_tcp_timeout_syn_recv' => 60,

    'ip_conntrack_tcp_timeout_syn_sent' => 120,

    'ip_conntrack_tcp_timeout_time_wait' => 120,

    'ip_conntrack_udp_timeout' => 180,

    'ip_conntrack_udp_timeout_stream' => 240



    Muss hier etwas angepasst werden?

    Minimalwert laut Knowledgebase muss ja dann 61 sein.

    Vielen Dank für ihre Antwort.

    Leider weiß ich nicht genau was Sie mit Reihenfolge meinen und werde deshalb daraus nicht schlau.


    Mit der Einstellung "statisch" kann doch keine Reihenfolge konfiguriert werden, oder meinen Sie die COR-Regeln?


    Folgendes ist konfiguriert:


    pasted-from-clipboard.pngpasted-from-clipboard.pngpasted-from-clipboard.pngpasted-from-clipboard.pngpasted-from-clipboard.png



    Bei ausgehenden Anrufen wird aber laut Auswertung die Connect Leitung verwendet:


    pasted-from-clipboard.png


    Bei eingehenden Anrufen die Telekom Leitung:


    pasted-from-clipboard.png


    Und das sehe ich auch im Connect Portal:


    pasted-from-clipboard.png



    Deswegen auch die Frage sind da jetzt zusätzliche Verbindungskosten entstanden.

    Falls ja hat mein Starface Partner, der die Cloud Instanz hochgezogen hat, hier wohl Mist gebaut!


    Meiner Meinung nach müsste auf der Telekom Leitung auch Clip No Screening und maximale Verbindungen 6 konfiguriert sein, weil das ist bei der Telekom gebucht.


    Wenn die Connect Leitung nicht mehr "im ausgehenden Routing berücksichtigt" wird, funktioniert keine Umleitung aus Handy mehr.

    Nein, unsere Benutzer arbeiten nicht mit Teamviewer.

    Zwar ist ein Teamviewer Quick Support für Fernwartungzwecke verfügbar, dieser wird allerdings nur im Supportfall von den Benutzern gestartet und läuft nicht als Dienst im Hintergrund.

    Aber ein "lustiger" Bug, werde ich im Hinterkopf behalten. Danke.

    Guten Tag,


    unsere Starface wird mit einem Telekom SIP betrieben und wurde durch unseren Partner eingerichtet.


    Nun ist mir, zuerst im Connect Portal und bei der Prüfung der Auswertung auf der Starface selbst, aufgefallen, dass abgehende Anrufe durch die Starface Connect Leitung aufgebaut werden (Nr.1) und nicht durch unseren Telekom SIP (Nr.2).


    Komischerweise funktioniert das auch, und zwar auch mit unserer Telekom Rufnummer?

    Routing steht auf "statisch" und auf der Connect Leitung ist "Leitung im ausgehenden Routing berücksichtigen" aktiv.
    "Diese Leitung erhält höchste Routing-Priorität bei Rufen in das nationale Festnetz / Mobilfunknetz" ist auf der Connect Leitung deaktiviert und auf der Telekom Leitung sind diese zwei Konfigurationsoptionen nicht vorhanden.


    Ich bezweifle aber das dies so korrekt ist und frage mich auch ob uns nun Zusatzkosten erwarten da ja Connect verwendet wurde?


    Meiner Meinung nach gibt es nun zwei Möglichkeiten das auf unseren Telekom SIP umzukonfigurieren:


    1. "Leitung im ausgehenden Routing berücksichtigen" auf der Connect Leitung deaktivieren. (Funktioniert dann NEON noch?)

    2. Im Routing von "Statisch" auf "Leitung" umstellen


    Welche Vor- und Nachteile haben die beiden Methoden, welche würdet ihr bevorzugen und warum?
    Wäre es möglich einen Fallback auf die Connect Leitung zu machen, wenn entweder der Telekom SIP ausgebucht (max. 6 gleichzeitige Verbindungen) oder ausgefallen ist?

    Guten Tag Herr Neidhardt,


    das ist mir schon klar, das war aber auch nicht die Frage.


    Starface tritt ja mit ihren Connect Angebot als ISP auf.

    Entsprechend muss Starface ja Peeringkapazitäten an den Internetknoten zu anderen ISP gebucht haben.


    Wie sind diese?

    Wie sieht das Routing in den asiatischen Raum aus?

    Hi Thomas, das ist ja interessant!

    Mir scheint, das der Installer den Plantronics Hub manchmal einfach nicht erkennt, warum auch immer. Dienst läuft etc.


    Der Workaround scheint praktikabel. Ich wusste gar nicht, dass die UCC dann den Plantonics Hub triggert.

    Allerdings können die "normalen" Benutzer den Autostart des Hubs nicht deaktivieren, nur der Admin darf.

    Wie habt ihr das ausgerollt?


    Parallel kämpfen wir auch damit, dass einige Anrufe viel zu leise sind.

    Audiolautstärke im Windows über die Kopfhörer ist gut.

    Auch nicht jeder Anruf ist leise.

    Aber gelegentlich sind Anrufe so leise das nichts verständlich ist.


    Ein dir bekanntes Phänomen?
    Einstellungen im Hub sind Lautstärkenbegrenzung etc. deaktiviert

    Guten Tag,


    wie sind den die Peering Kapazitäten in den indischen und asiatischen Bereich?


    Aktuell eine Neon Konferenz mit knapp 15 Teilnehmern aus Indien, Malaysia, Singapur etc. veranstaltet.


    War wenig funktional. Ständig komplette Aussetzer.

    Für Teilnehmer aus Deutschland war alles prima.

    Die Teilnehmer aus den genannten Gebieten haben auch keine "Schrottleitung", sind internationale Konzerne.


    Und dafür nach aktuellem Preismodell 130€ im Monat... :thumbdown:

    Hi, wir hatten ein ähnliches Phänomen:


    Rollout 50 Clients, Poly SAVI 8210 UC / 8220 UC, Starface Cloud 7.2..0.5, Starface Windows Client 7.2.0.153, Windows 10 21H2, Plantronics Hub 3.24.2.


    Im Vorfeld zum Starface Windows Client Rollout, wurden die Headsets verteilt und die Plantronics Hub installiert.

    Wochen später, als die Cloud Instanz ready war und die User sich auch daran anmelden konnten, wurde der Starface Client ausgerollt.

    Dabei wurden alle Komponenten des Windows Clients bis auf den Fax Drucker installiert,


    Bei einigen Clients wurde aber Starface nicht im Plantronics Hub als SDK fähiges Softphone registriert.


    Deinstallation, Reboot und Neuinstallation des Starface Win Clients hat diese Problematik behoben.


    Allerdings, sobald die Starface korrekt im Plantronics Hub registriert ist, funktioniert die Rufannahme über das Headset.

    Guten Tag,


    werden die Ports 40000 bis 60000 auch für externe Konferenzteilnehmer benötigt?


    Ich sehe hier große Problematiken in restriktiven Umgebungen.


    Zudem sind das ja jetzt nicht klassische "WebRTC Ports" wie z.B. 3478 für TURN Protokoll etc.


    Wäre eine volle Funktionalität allein über Port 443 gegeben?