Wir schweifen ab. Aber klar - warum nicht, voll gerne 
Wenn du wirklich mit einer 3CX Probleme hast, anfragst oder ein Ticket aufmachst bekommst du das (bisher) direkt und sofort gesagt: kein Support.
Das ist eine Debian 3CX auf Blech. Da ist das nicht mehr ganz so trivial oder gar intuitiv wenn man das komplett per SSH (ohne erforderlichen lokalen Benutzereingriff) lösen will. Aber ja, mit ein wenig Wissen ist das gar kein Problem und innerhalb weniger Minuten gelöst. Aber das ist egal.
Mir ging es eher darum, dir zu zeigen wie die Reaktionen seitens 3CX ausfallen. Das haben sehr viele offiziell beschäftigte 3CXler gelesen. Da kommt: produktiv nichts - weil nicht unterstützt.
Eine solches Echtzeitsystem (nix buffer, UDP realtime audio streams inkl. en- und decoding u.v.a.m.) darf man bitte nicht mit beliebigen 99% xyz content Servern vergleichen die einfach nur stumpf ab Layer 4 Daten liefern. Siehe Thema Netzwerkbindung, Multicast und weitere rd. 20 Themen die da ab Layer 2 laufen / laufen müssen. Telefoniesysteme werden nicht umsonst vielerorts auf nacktem Blech betrieben. Daher die wohldefinierten Beschreibungen von 3CX für eine mögliche Virtualisierung. Andere Anbieter haben das nicht.
Etwas später schreibst du erstmals von einem extern lfd. System. Da mag es sein es, obige Betriebsanforderungen treffen weniger auf dein Szenario zu. Da übernimmt beim Großteil der weltweit eingesetzten Endgeräte der generöserweise kostenlos von 3CX für unbegrenzte Nutzung bereitgestellte 3CX SBC diese niedrigschwellige Anbindung.
Entschuldigung bitte dafür dass ich so Oberlehrerhaft schreibe.
Meine Frage nach warum Incus war die Annahme nach einem wirklich größeren zentralisiert verwaltetem System oder eben gar einem Mainframe als Unterbau. Das ist es wohl eher nicht.
Meine Erfahrung: Andere Virtualisierer so wie z.B. PVE und auch Hyper V kann man wunderbar zentralisiert verwalten und auch ausschließlich per CLI bis in alle Ecken und auch per API steuern. Beide skalieren sehr groß und es wird eben speziell bei letzterem durchgehend Unterstützung von allen beteiligten Herstellern (HW und SW) für vordefinierte Umgebungen geboten. Es gibt ein größeres Universum an Werkzeugen vom Hersteller und Drittanbietern dafür (das reicht nicht in allen Ecken an VMWare heran). Darum geht es letztendlich i.d.R. beim professionellen Einsatz, auch in Richtung Zertifizierung, Absicherung, Versicherung und Nachweis davon. Aber ich will da definitiv keine Lanze für MS Prdukte brechen.
Aber gern zurück zum Thema des Thread: dein ursprüngliches Problem sollte ja grundsätzlich gelöst sein. Ausgenommen das Thema Virtualisierung in einem von 3CX unterstützten Betrieb.
Ich gebe zu: das steht nicht explizit da sondern eher indirekt. Ist nicht nett, daher der Hinweis. 3CX Debian z.B. virtualisiert auf Hyper V muss Gen1 sein. Das bedeutet: MBR boot.
Wenn du wirklich mit einer 3CX Probleme hast, anfragst oder ein Ticket aufmachst bekommst du das (bisher) direkt und sofort gesagt: kein Support.
nein
Das nur ist gut.
Das ist eine Debian 3CX auf Blech. Da ist das nicht mehr ganz so trivial oder gar intuitiv wenn man das komplett per SSH (ohne erforderlichen lokalen Benutzereingriff) lösen will. Aber ja, mit ein wenig Wissen ist das gar kein Problem und innerhalb weniger Minuten gelöst. Aber das ist egal.
Mir ging es eher darum, dir zu zeigen wie die Reaktionen seitens 3CX ausfallen. Das haben sehr viele offiziell beschäftigte 3CXler gelesen. Da kommt: produktiv nichts - weil nicht unterstützt.
nein, wenn 3CX dann definitiv kein Container
Eine solches Echtzeitsystem (nix buffer, UDP realtime audio streams inkl. en- und decoding u.v.a.m.) darf man bitte nicht mit beliebigen 99% xyz content Servern vergleichen die einfach nur stumpf ab Layer 4 Daten liefern. Siehe Thema Netzwerkbindung, Multicast und weitere rd. 20 Themen die da ab Layer 2 laufen / laufen müssen. Telefoniesysteme werden nicht umsonst vielerorts auf nacktem Blech betrieben. Daher die wohldefinierten Beschreibungen von 3CX für eine mögliche Virtualisierung. Andere Anbieter haben das nicht.
Etwas später schreibst du erstmals von einem extern lfd. System. Da mag es sein es, obige Betriebsanforderungen treffen weniger auf dein Szenario zu. Da übernimmt beim Großteil der weltweit eingesetzten Endgeräte der generöserweise kostenlos von 3CX für unbegrenzte Nutzung bereitgestellte 3CX SBC diese niedrigschwellige Anbindung.
Entschuldigung bitte dafür dass ich so Oberlehrerhaft schreibe.
Meine Frage nach warum Incus war die Annahme nach einem wirklich größeren zentralisiert verwaltetem System oder eben gar einem Mainframe als Unterbau. Das ist es wohl eher nicht.
Meine Erfahrung: Andere Virtualisierer so wie z.B. PVE und auch Hyper V kann man wunderbar zentralisiert verwalten und auch ausschließlich per CLI bis in alle Ecken und auch per API steuern. Beide skalieren sehr groß und es wird eben speziell bei letzterem durchgehend Unterstützung von allen beteiligten Herstellern (HW und SW) für vordefinierte Umgebungen geboten. Es gibt ein größeres Universum an Werkzeugen vom Hersteller und Drittanbietern dafür (das reicht nicht in allen Ecken an VMWare heran). Darum geht es letztendlich i.d.R. beim professionellen Einsatz, auch in Richtung Zertifizierung, Absicherung, Versicherung und Nachweis davon. Aber ich will da definitiv keine Lanze für MS Prdukte brechen.
Aber gern zurück zum Thema des Thread: dein ursprüngliches Problem sollte ja grundsätzlich gelöst sein. Ausgenommen das Thema Virtualisierung in einem von 3CX unterstützten Betrieb.
