3CX - QOS - Webclient - iOS App

[fabs]

Hallo miteinander,

wir betreiben 3CX V16 als Debian HyperV-VM auf einem Windows 10 LTSC Client.
Wir verwalten 12 Nebenstellen ausschließlich über den Webclient und/oder iOS/Android App.
Als SIP Provider verwenden wir Vodafone (Privat) mit mehreren SIP Trunks.
Als Router verwenden wir eine Fritzbox 7530 VDSL 250/40 und als Switchs Cisco SG350X und Unifi AC-Pro als Access Points.
Auf den Cisco Switchs sind zwei VLANs erstellt. VLAN10 ist 192.168.10.0 (Gateway Fritzbox 7530) und VLAN30 192.168.30.0 (Gateway zu einem anderen Router (seperate Internetleitung). Im Erdgeschoss befindet sich die Fritzbox 7530, die 3CX VM und 1 Cisco SG350X. Im Untergeschoss befindet sich ebenfalls ein Cisco SG350X. Beide Switche sind via 10G Glas Trunk verbunden.
Dir Webclients und iOS App User sind ausschließlich im VLAN10 192.168.10.0
Der Firewallcheck läuft ohne Probleme und auch das Telefonieren funktioniert soweit eigentlich recht gut.
Es gibt aber Momente, ich denke bei Auslastung der Leitung, dass die Sprachqualität nachlässt, oder die Verbindung kurzzeitig abbricht.

Wenn ich das richtig sehe, macht es ja keinen Sinn auf dem Cisco Switch ein Voice LAN zu erstellen, da wir ja eh nur Webclients und iOS App benutzen?
In der Fritzbox kann ich bezüglich QOS auch nicht viel einstellen, da ich denke die Fritzbox Internettelefonie generell bevorzugt. Jedenfalls kann ich "Internettelefonie" nur auf alle Endgeräte priorisieren.

Gibt es denn eine Möglichkeit dennoch die Webclients und iOS App User zu priorisieren?

Viele Grüße
Fabian

 

[oldunify]

Hallo Fabian,

ich meine, dass man QoS nicht explizit bei der FritzBox aktivieren kann - womöglich gibt es hier die Abhängigkeit mit "Internettelefonie", wie Du ja auch schon schriebst.

Ich würde empfehlen, Dir mal die Codecs bzw. deren Reihenfolge anzusehen. Das haben wir auch gemacht und seitdem sehr gute Sprachqualität "erlangt".

Im Management unter Allgemein:




Und dann jeweils für jede! Nebenstelle explizit angepasst und entsprechend provisioniert:




Bei den Nebenstellen "lassen" wir gar nichts anderes mehr "zu". Ich weiß, dies kann zu Transkodierungen führen, die die Sprachqualität erheblich verschlechtern - wir haben dies aber bisher nicht feststellen können (250 User). Allerdings haben wir keinerlei Abbrüche, da wir breitbandige, synchrone WAN-Anbindungen haben.

Vielleicht konnte ich Dir ja ein wenig helfen - teste das bitte gern einmal aus.


Viele Grüße, Remo

 

[fabs]

Hallo Remo,

vielen Dank für den Hinweis. Ich habe jetzt unter Allgemein wie du auch beschrieben die Codecs sortiert.
Wie schaut es denn bei der Reihenfolge der Codec Priorität bei "externen" Anrufe aus?
Beim SIP Trunk selbst kann die Codec-Reihenfolge auch gesetzt werden. Wie sind hier die Erfahrungen?
Wie bereits erwähnt, verwenden wir ja ausschließlich den Webclient bzw. iOS/Android App, somit ist unter Nebenstellen -> Telefon-Provisionierung -> Eigene Telefone "3CX App" die Codec-Reihenfolge wie folgt:


Sollten wir in diesem Falle bestimmte Codecs entfernen?

Viele Grüße
Fabian

 

[oldunify]

Guten Morgen Fabian,

hatte ich tatsächlich "unterschlagen" - hier hatten wir das entsprechend auch angepasst nämlich:




Durch schlechte Codec-Aushandlung beim SIP haben wir "tabula rasa" gemacht und alle drei Codec-Optionen ("Allgemein", SIP-Trunk und Nebenstellen) angepasst. Wir haben uns also nicht herangetastet und nach dem Trial'n Error-Prinzip alles analysiert. Mit dieser "Strategie" sind wir aber bisher sehr gut gefahren - aktuell prüfen wir, ob unsere Probleme mit Konferenzen hier im Zusammenhang stehen - es könnte sein, dass die 3CX hier transkodiert, was zu schlechter Sprachqualität führt - einzelne Gespräche sind aber immer G.722 oder G.711 - ganz selten mal G.729.

Die Codec-Reihenfolge bei den Nebenstellen ist von Dir/Euch geändert worden oder? Per Default ist nach der Anlage einer neuen Nebenstelle die Reihenfolge wie folgt:




Zu Deiner Frage nach dem Entfernen bestimmter Codecs:

ich bin in erster Linie Systemadministrator und kein TK-/SIP-Spezialist und arbeite mit gerade erst so richtig in SIP hinein - grundsätzlich gehe ich davon aus, dass sich 3CX was bei der Anzahl/Reihenfolge der Codecs gedacht hat (vielleicht aber auch nur in erster Linie "Stabilität"). Die Sprachqualität mit dem GSM-Codec ist mit Headset unterirdisch (im Vergleich zur gewohnten HD-Telefonie) - wir wollten uns das nicht antun, weswegen wir zumindest GSM rausgenommen haben.G-711-U-Law ist meines Wissens nach nur in Nordamerika und Japan "vertreten" (a-law ja in Europa vorherrschend), weswegen wir uns diesen "geschenkt" haben ... ich weiß, SIP-Calls von Providern aus Amerika könnten sich dann ggf. nicht auf G.711 einigen ... Wir haben primär den deutschen Markt und angrenzende europäische Länder im Fokus.


Viele Grüße, Remo

 

[fabs]

Hallo Remo,

dein erstes Bild beschreibt die Codec-Reihenfolge des SIP-Trunks, richtig? Ich habe diese Reihenfolge nun auch mal bei allen SIP-Trunks angepasst.

Ganz genau, die Codec Reihenfolge der Nebenstellen wurde schon von uns in der Vergangenheit mal angepasst.
Ich habe dort nun aber auch folgende Reihenfolge angewandt: G722, A-law, G729.

Unsere Kunden liegen auch hauptsächlich im deutschen und europäischen Raum. Vereinzelt haben wir aber auch Anrufe aus Afrika, Nah-Ost.


Als Überblick habe ich nun folgende Codec-Reihenfolge angewandt

SIP-Trunks:


Nebenstellen:


Einstellungen -> Allgemein:


Viele Grüße
Fabian

 

[oldunify]

Richtig, mein erster Screenshot ist vom SIP-Trunk.

Exakt so haben wir es aktuell auch - teste bitte gern mal, ob sich was bei Euch geändert hat. Kurzes Feedback wäre schön, danke!


Viele Grüße, Remo

 

[fabs]

Hallo Remo,

perfekt, dann werde ich das Ganze mal testen und hoffentlich später positiv berichten.
Ich muss dazu sagen, dass wir mit den Webclients die via LAN angebunden sind, auch zum größten Teil keine Probleme hatten, uns is das eher bei den Handynutzern aufgefallen. Ich gehe aber eher davon aus, dass dies auf die Thematik zurückzuführen ist, wenn der Mitarbeiter durchs Gebäude läuft und dabei ein Wechsel des Accesspoints geschieht.

Viele Grüße
Fabian

 

[oldunify]

Hallo Fabian,

wie ist nach fast einer Woche der Stand?

Ich hatte tatsächlich Eure Nutzung der Mobile-App nicht ganz auf dem "Schirm", obwohl Du dies eingangs erwähnt hattest.

Zur Nutzung der mobilen App - egal ob nun iOS oder Android - kann ich tatsächlich auch "beitragen", dass diese nicht optimal laufen - bei uns haben zwar viele Nebenstellen (~250) auch eine App-Nutzung - diese kommt aber eher primär zur Anwendung, wenn die Ma/in unterwegs, im Home-Office oder sich an einem anderen Standort aufhalten. Hierbei zeigt sich, dass trotz guter WLAN-Abdeckung sporadisch die Verbindung abbricht - die App signalisiert mit einem Doppel-Piepsen, dass ein Link-Loss oder schlechtes Signal angeblich vorhanden wäre - das Smartphone selbst hat zu diesem Zeitpunkt aber eine gute WLAN-Abdeckung. Im heimischen WLAN sind die Probleme kaum bis gar nicht vorhanden, weshalb wir das bis dato stets auf unsere WLAN-Infrastruktur zurückgeführt haben. Um nicht allzu "schwammig" technisch rüberzukommen, müssten wir das mal tracen und sniffen - mangels Zeit noch nicht weiter mit beschäftigt.

Viele Grüße und schöne Ostertage

 

[fabs]

Hallo Remo,

bisher kann ich noch keine negativen Aussagen treffen. Bisher läuft es auf den Webclients stabil.
Bei Nutzung der Smartphone App haben wir genau exakt die selbe Problematik die du auch beschreibst.
Man hört kurz ein piepsen, der Balken wird orange/rot und die Verbindung bricht kurzzeitig ab. Die WIFI Verbindung ist aber nach wie vor sehr gut.

Unsere Mitarbeiter sind leider auf die Smartphone App angewiesen, da viele von uns durch das Haus springen müssen. Produktion -> Lager -> UG -> OG etc.
Die WIFI Accesspoint Abdeckung würde ich aber nicht anzweilfeln, da diese nach meiner Kenntnis gut abgestimmt ist. Wenn der Mitarbeiter vom UG ins OG geht,kann natürlich ein kurzzeitger Ausfall stattfinden, da er dabei den AP wechselt. Wobei wir das mit dem Verbindungsabbruch aber auch innerhalb des AP haben.
Wir werden das weiterhin beobachten.

Viele Grüße und schöne Ostertage
Fabian

 

[avraammich_3CX]

Hi,

bezüglich connection und piepsen würde würden bekannte problem schon in der neuen Beta Version behoben.

3CX App for Android Build History

Review all the changes made to 3CX Application for Android . Build History / Change log updated from version 1.1.10 to current version.

www.3cx.com

Siehe Build History:

3CX App for Android Build History

Review all the changes made to 3CX Application for Android . Build History / Change log updated from version 1.1.10 to current version.

www.3cx.com

Falls Beta nicht weiterhilft, würde evt.l das Log des 3cx Clients oder iOs Client(beta) weiterhelfen das Verhalten zu verstehen.

 

[oldunify]

Vielen Dank für die Info bzgl. Fixen in der Beta-Version. Und irgendwie beruhigend, dass das offenbar ein "known issue" ist.

Wir "tun" uns aktuell noch etwas "schwer", eine Beta in der Live-Umgebung einzusetzen. Ich schaue mit einem Auge öfter mal in die Change Logs von den Betas - wirklich sehr interessant! Was ich aber leider nicht ganz nachvollziehen kann, dass bekannte Fehler in Final-Release-Versionen nicht gefixed werden - eine Lösung ist ja offensichtlich vorhanden (womöglich aber nicht in der Final-Release-Version (V16)). Und ja, ich kann verstehen, dass man neue Feature in neue Versionen pushed und dort auch Bugfixing betreibt oder Probleme aus anderen Versionen technisch anders implementiert, so dass sie dann laufen. Es ist nicht böse gemeint!


Viele Grüße, Remo

 

[oldunify]

Wobei wir das mit dem Verbindungsabbruch aber auch innerhalb des AP haben.

Ja, genauso ist es bei uns auch - innerhalb eines APs passieren die Verbindungsabbrüche und Pieps-Feedbacks - selbst wenn man direkt neben den AP steht.

 

[oldunify]

Vielen Dank für die Info bzgl. Fixen in der Beta-Version. Und irgendwie beruhigend, dass das offenbar ein "known issue" ist.

Wir "tun" uns aktuell noch etwas "schwer", eine Beta in der Live-Umgebung einzusetzen. Ich schaue mit einem Auge öfter mal in die Change Logs von den Betas - wirklich sehr interessant! Was ich aber leider nicht ganz nachvollziehen kann, dass bekannte Fehler in Final-Release-Versionen nicht gefixed werden - eine Lösung ist ja offensichtlich vorhanden (womöglich aber nicht in der Final-Release-Version (V16)). Und ja, ich kann verstehen, dass man neue Feature in neue Versionen pushed und dort auch Bugfixing betreibt oder Probleme aus anderen Versionen technisch anders implementiert, so dass sie dann laufen. Es ist nicht böse gemeint!


Viele Grüße, Remo

Ich muss mich berichtigen - ich hatte mich in letzter Zeit mit der V18 auseinander gesetzt und bin gedanklich von der hier erwähnten Beta (V16!) ins Schleudern geraten - hatte es auf die V18 bezogen ... War keine böse Absicht - entschuldigt bitte!


Viele Grüße, Remo