9
FreePBX als neue Telefonanlage
Hallo zusammen,
wir möchten unsere in die Jahre gekommene Aastra OpenCom 510 komplett ersetzen. Unser Budget ist bei 40'000 CHF (ca. 35'000 Euro).
Wir überlegen einen SIP-Trunk (sipcall) mit einem eigenen internen Server mit freePBX inkl. komplett neuen Tisch-Telefone (50x Snom D765), neuen DECT-Geräte (20x Snom M65) und entsprechend noch ca. 7-8 Snom M700.
Aktuell haben wir einen 100-er Nummerblock mit 15 Amtsleitungen (=gleichzeitige Gespräche). Zusätzlich noch einen Fax (der sollte aber durch Cisco SPA kein Problem darstellen).
Wie muss der Server ausgestattet sein damit er das stemmen kann (Prozi, Ram, Netzwerkkarten)? Ich denke ein physischer Server wäre besser als einen Virtuellen auf unseren Hyper-V Hoster...(??)
Netzwerktechnisch haben wir an unserem Standort einen Internet-Anschluss mit 1Gb/s (FTTH sei Dank). Die Telefonie wird über eigenes VLAN geführt, die Switche sind mit PoE ausgestattet.
Wie sieht es mit Backup/Redundanz aus? Grundsätzlich stelle ich mir einen Linux-Server so vor, dass er einfach läuft ohne grosse Probleme.
Wir möchten aber nicht nur die PBX-Config speichern, sondern idealerweise die Möglichkeit haben den Server innerhalb von wenigen Stunden auf einen neuen Server zu "klonen" falls Hardwaremässig etwas defekt wird. Was könnt ihr da empfehlen?
Veeam Backup der ganzen Linux-Installation möglich (hat da Jemand Erfahrung)?
Sollten noch wichtige Infos fehlen, liefere ich die gerne nach.
Danke und lg, Manuwj
wir möchten unsere in die Jahre gekommene Aastra OpenCom 510 komplett ersetzen. Unser Budget ist bei 40'000 CHF (ca. 35'000 Euro).
Wir überlegen einen SIP-Trunk (sipcall) mit einem eigenen internen Server mit freePBX inkl. komplett neuen Tisch-Telefone (50x Snom D765), neuen DECT-Geräte (20x Snom M65) und entsprechend noch ca. 7-8 Snom M700.
Aktuell haben wir einen 100-er Nummerblock mit 15 Amtsleitungen (=gleichzeitige Gespräche). Zusätzlich noch einen Fax (der sollte aber durch Cisco SPA kein Problem darstellen).
Wie muss der Server ausgestattet sein damit er das stemmen kann (Prozi, Ram, Netzwerkkarten)? Ich denke ein physischer Server wäre besser als einen Virtuellen auf unseren Hyper-V Hoster...(??)
Netzwerktechnisch haben wir an unserem Standort einen Internet-Anschluss mit 1Gb/s (FTTH sei Dank). Die Telefonie wird über eigenes VLAN geführt, die Switche sind mit PoE ausgestattet.
Wie sieht es mit Backup/Redundanz aus? Grundsätzlich stelle ich mir einen Linux-Server so vor, dass er einfach läuft ohne grosse Probleme.
Wir möchten aber nicht nur die PBX-Config speichern, sondern idealerweise die Möglichkeit haben den Server innerhalb von wenigen Stunden auf einen neuen Server zu "klonen" falls Hardwaremässig etwas defekt wird. Was könnt ihr da empfehlen?
Veeam Backup der ganzen Linux-Installation möglich (hat da Jemand Erfahrung)?
Sollten noch wichtige Infos fehlen, liefere ich die gerne nach.
Danke und lg, Manuwj
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 362534
Url: https://administrator.de/contentid/362534
Printed on: April 26, 2024 at 03:04 o'clock
9 Comments
Latest comment
Moin,
warum kaufst du nicht einfach eine Applliance?
Natürlich könnte man die Angaben auch als "Vorlage" nutzen
Gruß
Zitat von @manuwj:
Wie muss der Server ausgestattet sein damit er das stemmen kann (Prozi, Ram, Netzwerkkarten)?
Wie muss der Server ausgestattet sein damit er das stemmen kann (Prozi, Ram, Netzwerkkarten)?
warum kaufst du nicht einfach eine Applliance?
Natürlich könnte man die Angaben auch als "Vorlage" nutzen
Gruß
Hast du damit erfahrung? Ansonsten viel Spass bei der Jobsuche! Du hast bei VoIP auch Netzwerkmässig einiges zu beachten (sowohl rechtlich als auch technisch). Dann muss dir klar sein das du ne menge da selbst konfigurieren musst - je nach System auch mal in Textdateien... Nicht falsch verstehen - ich mag meine Asterisk, aber wenn man sowas aufbaut sollte man wissen was man tut. Ich würde die bis heute nicht mit meinen Kenntnissen in einer Firma als "Standalone" betreiben wollen...
Das hatte ich gar (noch) nicht in Betracht gezogen. Scheint mir eine sehr gute Alternative zu sein. Hast du hier Erfahrungen bzw. einen Ansatz wie man die "Ausfallsicherheit" regeln könnte?
Danke, Manuwj
Danke, Manuwj
Zitat von @maretz:
Ich würde die bis heute nicht mit meinen Kenntnissen in einer Firma als "Standalone" betreiben wollen...
Mit den genannten Appliance aber schon... oder auch nicht?Ich würde die bis heute nicht mit meinen Kenntnissen in einer Firma als "Standalone" betreiben wollen...
Danke, Manuwj
Hi,
da ich "Hyper-V" Host lese...
Hast du Erfahrung mit Unix Systemen?
Wenn nein, dann wäre bei dem Budget evtl. auch 3CX eine mögliche Lösung um das ganze in eine Windows Umgebung einzupflegen.
LG, Manu
da ich "Hyper-V" Host lese...
Hast du Erfahrung mit Unix Systemen?
Wenn nein, dann wäre bei dem Budget evtl. auch 3CX eine mögliche Lösung um das ganze in eine Windows Umgebung einzupflegen.
LG, Manu
Warum setzt ihr nicht einfach eine Mitel100 als Gateway vor die 510? Die 510 bleibt dann nur noch als Schnittstellenerweiterung. Kostet wenig und bringt viel. Ich finde die 6800er SIP Telefone von Mitel gut und das SIP-DECT ist weit besser als das Snom M700.
Gruß,
Christoph
Gruß,
Christoph
Der Server wird von Jemandem aufgesetzt, der dies schon in verschiedenen KMU's gemacht hat (und diese sind auch sehr zufrieden). Allerdings sind wir nun etwas grösser als die paar KMU's. Von daher wollte ich einfach mal hören, was die Administrator.de-Community dazu meint 
Hast du da negative Erfahrungen? Die produkt-Beschreibung von Snom lobt das Teil in höchsten Tönen. Klar, man kann Niemandem trauen, aber trotzdem so schlecht kann das ja nicht sein, oder?
Lg, Manuwj
Hast du da negative Erfahrungen? Die produkt-Beschreibung von Snom lobt das Teil in höchsten Tönen. Klar, man kann Niemandem trauen, aber trotzdem so schlecht kann das ja nicht sein, oder?
Lg, Manuwj
Am meisten stört mich eigentlich dass das Teil nur mit SNOM Endgeräten kann die wie ich finde exorbitant überteuert sind, GAP kann das garnicht. Die Endgeräte fühlen sich aber sehr wertig an. Die M700 finde ich in der Synctopologie ein wenig bizarr. Wir hatten das System mal bei uns in der Firma getestet und hatten immerwieder unerkläriche Gesprächsabbrüche und sind nach tagelangem tracen mit Wireshark wieder zum Mitel SIP DECT zurück weil bei uns quasi jeder mit DECT und Bluetooth Headset rumläuft. Bluetooth gibts ja bei Snom erst mit dem ewig schweren IP65 Handteil das 300+€ kostet. OEM Hersteller ist übrigens RTX (https://www.rtx.dk/en/business-communications/odmoem-products/#section14 ..) btw., gibts ja auch als Agfeo etc.
Was mir an der Kombination Mitel100 und Mitel SIP DECT sehr gut gefällt ist die Tatsache dass das DECT wirklich nahtlos in die Bedienoberfläche der Mitel100 integriert ist, man merkt eigentlich nicht ob es 2draht DECT oder SIP Dect ist, es funktioniert einfach.
Das ist übrigens die Lösung die ich machen würde wenn ich eine Opencom hätte:
https://www.komsa-nordwest.com/hersteller/mitel/news/artikel/all-ip-migr ...
Webinterface etc. läuft alles auf der Mitel100, die klassischen Ports kommen von der alten 510er. Vorteil ist einfach ein durchgängiges Bedienkonzept, das geht mir bei den ganzen SIP Anlagen immer ab, da heisst dann die Taste fürs Verbinden an den Tischtelefonen wieder anders als auf den Schnurlosen etc.
Was mir an der Kombination Mitel100 und Mitel SIP DECT sehr gut gefällt ist die Tatsache dass das DECT wirklich nahtlos in die Bedienoberfläche der Mitel100 integriert ist, man merkt eigentlich nicht ob es 2draht DECT oder SIP Dect ist, es funktioniert einfach.
Das ist übrigens die Lösung die ich machen würde wenn ich eine Opencom hätte:
https://www.komsa-nordwest.com/hersteller/mitel/news/artikel/all-ip-migr ...
Webinterface etc. läuft alles auf der Mitel100, die klassischen Ports kommen von der alten 510er. Vorteil ist einfach ein durchgängiges Bedienkonzept, das geht mir bei den ganzen SIP Anlagen immer ab, da heisst dann die Taste fürs Verbinden an den Tischtelefonen wieder anders als auf den Schnurlosen etc.
