Asterisk - Erfahrungsberichte/Best pracrise gesucht!

[foschi]

Hallo sisko-m,

grundsätzlich ist für viele Anforderungen im Bereich TK-Systeme Asterisk eine sinnvolle Lösung, wobei es Alternativen gibt die ggf. besser passen. Hier erstmal nur zu Asterisk.

Auch wir haben in 2004 mit kartenbasierten Asterisk-Systemen angefangen, und sind vor ca. 3 Jahren auf Mediengateways umgestiegen, da uns das Gebastel von mISDN und bristuff oder alternative Ansätze wie chan_woomera immer wieder vor nicht bzw. schlecht lösbare Probleme gestellt hat. Hinzu kommen noch je nach Version Probleme im Asterisk, die dort mit hineinspielen.

Durch den Umstieg auf Mediengateways können wir stabile Asterisk-Server in beliebigen Größenordnungen (Portanzahl) umsetzten, und vor allem die sonst eher problematischen Themen Fax (T.38), abgesetzte ISDN S0-Ports bzw. abgesetzte Anlagen-Teile oder -Anschlüsse problemlos umsetzen. Hardware-Abhängigkeiten (Anzahl Ports, Bussysteme, Modulprobs) zwischen Server und Interface-Karte stellen für uns so keine Probleme mehr dar.

Durch die Medien-Gateways wurden wir flexibler in der Betriebstechnik bei gleichzeitig höherer Stabilität, verglichen mit kartenbasierten Systemen grad im BRI-Bereich (PRI ist auch mit Karten vergleichsweise unproblematisch). Für uns wichtig: ein technisch sinnvoller Support für Protokoll-Probleme, so wie er z.B. bei Patton oder Vegastream gegeben ist. Hat uns bei so manchen Anschaltungen, z.B. bei Q.SIG oder ausländischen Telefonnetzen, sehr weitergeholfen.

Die Funktionalität der Mediengateways deckt alle Anwendungsfälle ab denen man (bei Umsetzung eines TK-Systems) im Feld begegnet. Meiner Meinung nach wird Asterisk erst durch Mediengateways vergleichbar mit klassischen TK-Systemen, die ja auch Mediengateways nutzen.

Mediengateways haben für sehr spezielle Anwendungen den Nachteil, dass man nicht selbst die gewünschte Protokoll-Funktionalität umsetzen kann, sondern auf das Fixing des Herstellers angewiesen ist. Für uns (und unsere Kunden, und andere Dienstleister) überwiegt der funktionale und qualitative Vorteil der Mediengateways gegenüber den Kartenlösungen deutlich.

Besondere Einsatzbereiche von Asterisk, die nur mit Karte und ISDN Subsystemanpassung umsetzbar sind, werden von uns nicht berücksichtigt.

Wenn ich Dich richtig verstehe würdest Du klar empfehlen z.B. mit einem Patton ISDN GW die Anbindung ans PSTN zu realisieren!? Die Grundidee warum wir auf eine interne ISDN Karte gegangen sind war der Gedanke eine "Out of the Box" Lösung zu haben ohne weiteren externen SchnickSchnack.

Anbindung ISDN S2M/E1/T1/S0 und analog FXS/FXO mit Mediengateways ist auch eine klare Empfehlung von mir.

Den ersten Ansatz (mit Karten) verfolgen die meisten. Die og. Ausführungen zeigen aber, dass der Betrieb von Asterisk mit entkoppelten Schnittstellen oft der sinnvollere Weg ist.

Es macht auch den Anschein das bristuff nicht mehr wirklich Fortschritte macht bzw. grossartig weiterentwickelt wird. Wenn man sich dann die Alternativen wie MISDN oder chan_capi anschaut und da entsprechende Foreneinträge anschaut scheint das auch keine wirkliche Alternative zu sein.

Das haben wir auch beobachtet. Das "works4me"-Problem bei Opensource ist hier ein Nachteil, da nicht jeder firm in der Protokollimplementierung von ISDN und SIP ist, bzw. sich konzeptionell an Patches dafür wagt. Selbst wenn man dies realisiert (haben wir mal gemacht) ist es immer noch nur gepatcht, und führt zu neuen Problemen (Asterisk 1.0->1.x...)

Argumentativ sagen halt einige meiner Geschäftskollegen wenn man die Asterisk mit einem externen ISDN GW betreiben muss damit es funktioniert, kann man auch gleich MS OCS oder ähnliches einsetzen (sehe ich allerdings nicht so).

Die Aussage verkennt, dass hinter anderen Softswitches verschiedene Geschäftsmodelle mit Abhängigkeiten stehen. Mit Asterisk kann man eine Menge Anforderungen ohne diese Abhängigkeiten umsetzen.

- Welche Hardwarebasis wird verwendet (PC oder richtiger Server)
- Welche ISDN Karten verwendet ihr (wenn überhaupt)
- Mit welchen Treibern arbeitet Ihr (MISDN, bristuff oder chan_capi)?

Server von Supermicro, HP, Dell oder IBM, aufgrund der Qualität und des technischen Designs der Server-Hardware, teilweise auch wg. des geforderten Herstellersupports.

Mediengateways von Patton Inalp, nur die SmartNode-Reihe. Dadurch keine Karten und ISDN-Subsysteme notwendig.

- Welche Asterisk Version verwendet Ihr (mittlerweile hat man ja die Wahl zwischen 1.2, 1.4 oder 1.6 … )

Für unsere Installationen reicht 1.4, wobei wir bis Ende letzten Jahres noch 1.2 genutzt haben (Stabilität vs. Features). 1.6 kommt im Moment überhaupt nicht in Frage im Feldeinsatz.

- Welche Freepbx Version verwendet Ihr (wenn überhaupt)

Wir verwenden Gemeinschaft, und hatten vorher FreePBX. Gemeinschaft hat deutliche Vorteile gegenüber FreePBX, deren Betrachtung diesen Thread sprengen würde.

Wir haben Gemeinschaft für unsere Zwecke an vielen Stellen modifiziert, und verwenden zusätzlich noch eigene Software um um strukturelle Probleme des Asterisk herumzuarbeiten, und um zusätzliche Funktionalität am Endgerät darzustellen (XML-Menüs, LED-Steuerung, Server-Stati als Anzeige am Endgerät, serverübergreifende BLFs und noch ein paar Dinge mehr).

- Welche Festnetztelefone mit welchem Firmwarestand und welcher Konfig verwendet Ihr
- Welche Mobilgeräte (WLAN oder DECT) mit welchem Firmwarestand verwendet Ihr

snom-Endgeräte (3xx-Reihe, 7.1.39) werden von uns als Standard verwendet. Je nach Anforderungen und Kunde haben wir noch Polycom im Einsatz. Ein richtiges WLAN-System mit passenden Telefonie-Geräten (Cisco, Nortel/Trapeze etc.) ist nur bei sehr wenigen Kunden mit passenden Anforderungen sinnvoll; wir verwenden einheitlich Polycom/Kirk DECT-Systeme (IP600/3, IP6000) bzw. eine Integration von GSM-Geräten.

- Welche Codecs verwendet Ihr

G.711a, bei besonderen Anforderungen G.729.

- Sind Softphones zu empfehlen? Wenn ja welche?

Hab noch kein 100% brauchbares gefunden, die meisten kommen mit X-Lite aus.

Nochmal ein paar Gedanken:

- die BRI-Mediengateways sind ungefähr preisgleich mit den BRI-Karten (bei 4 Ports)
- die "Vehemenz" von Guard-X kann ich nur unterstützen (würden alle sich mal richtig informieren und div. Dinge ausprobieren wär das Forum deutlich weniger DAU-Fragen ausgesetzt)
- bei vielen Systemen und entsprechenden Einschränkungen könnte man auch mit einer Kartenlösung leben, hat dann aber auch die entsprechenden Probleme
- QoS haben wir nur bei einem (!) Kunden in Betrieb
- als Switche verwenden wir Nortel Networks, oder das was der Kunde vorgibt (aber keine Baumarkt-Switches)
- Guard-X und ich arbeiten nicht bei noch für Patton, sondern haben einfach eine ausreichende Menge Systeme mit Mediengateways in Betrieb, und jahrelange Erfahrungen mit Kartenlösungen - wir sind sozusagen technisch überzeugt
- die von sisko-m beschriebenen Probleme hab ich bei bisher keiner Installation beobachtet.

So, hab ich alle bedient?

 

[grandpa]

Hallo @all

sehr guter Beitrag, hat mich überzeugt. Ich verwende seit 2 jahren bei diversen Installationen ( bis zu 200 sip-clients) immer den Bristuff. Leider habe ich einige Probleme
mit der zuverlässigkeit. Nun werde ich auf Medien-Gateways umsteigen.
Ich verwende übrigens Freebpx, allerdings ebenfalls an vielen Stellen modifiziert.
Aber Gemeinschaft werde ich mir auch noch ansehen, dann für grössere Projekte.
Noch eine kurze Frage zu Medien Gateways, folgende habe ich mir rausgesucht:
(NT wird nicht verwendet)
Bri
Inalp SN 4552/2BIS/EUI VoIP SoHo Router ; 2 Kanäle
Inalp SN 4554 VoIP SoHo Router; 4 Kanäle
Inalp SN 4638 Gateway/Route; 8 Kanäle

PRI
Inalp SN 4960 Gateway SN4960/1E15V/UI ; 15 Kanäle
Inalp SN 4960 Gateway SN4960/1E30V/UI ; 30 Kanäle
Inalp SN 4960 Gateway SN4960/4E60V/UI ; 60 Kanäle

Diese Teile werden also zwischen den ("nun reinen") Voip-server und den Isdn/multiplexer
gehängt. Preislich ist das ok, ausser den SN 4552. Der würde auch nicht die komplette Funktionalität brauchen. Der SN 2552 ist entweder lokal oder im entfernten Standort vorgesehen (zentrale Asterisk über VPN). Aber wenn es dafür 100% zuverlässig ist, gehts das schon.
Ist das soweit ok?
Oder habe Ihr andere Vorschläge ?

gruss

 

[foschi]

Ich verwende übrigens Freebpx, allerdings ebenfalls an vielen Stellen modifiziert.

Wir hatten auch FreePBX deutlich modifiziert, und dann bei Gemeinschaft fast alle Modifikationen als Standardfunktionen vorgefunden.

Aber Gemeinschaft werde ich mir auch noch ansehen, dann für grössere Projekte.

Das funktioniert auch sehr gut für kleine Projekte

Bri
Inalp SN 4552/2BIS/EUI VoIP SoHo Router ; 2 Kanäle
Inalp SN 4554 VoIP SoHo Router; 4 Kanäle
Inalp SN 4638 Gateway/Route; 8 Kanäle

Ich würde ausschliesslich die SN463x-Geräte benutzen (integriertes Netzteil, robustes Metallgehäuse, 19"-Option, +1 ISDN S0-Port für diverse Zwecke).

PRI
Inalp SN 4960 Gateway SN4960/1E15V/UI ; 15 Kanäle
Inalp SN 4960 Gateway SN4960/1E30V/UI ; 30 Kanäle
Inalp SN 4960 Gateway SN4960/4E60V/UI ; 60 Kanäle

Ich würde auch hier nur die SN4960/4E/xx verwenden, die SN4960/1E/xx sind oft teurer als die SN4960/4E/xx.

 

[sisko-m]

Auch noch mal @all ein dankeschön an die vielen konstruktiven Antworten.

Ich denke so einen Thread gibt es selten (aus meiner Sicht) aus dem man so viele sinnvolle Informationen gewinnen kann.

Da ja doch die meisten die sich schon seit Jahren mit der Thematik beschäftigen (auch irgendwo verständlich) davor zurückschrecken Ihr "Kapital" im Sinne von Informationen preiszugegen.

Diesen Eindruck hatte ich in diesem Thread bisher nicht. Also noch mal Danke!

@foschi: Um nochmal ganz konkret auf Deine Antworten einzugehen.

Was die Karten Thematik angeht haben wir genau Deine Punkte auch feststellen können. Ich finde es halt etwas schade, um es freundlich zu umschreiben, das doch ein so grosser Markt wie Europa, wo ISDN ja flächendeckend im Einsatz, ist so wenig Berücksichtigung in Asterisk findet.
Dadurch lassen sich halt "ALL in ONE" Lösungen schwerlich umsetzen.

Was mich noch ein wenig umtreibt ist Dein Kommentar

Besondere Einsatzbereiche von Asterisk, die nur mit Karte und ISDN Subsystemanpassung umsetzbar sind

.. gäbe es denn da von Deiner Seite aus irgendein sinnvolles Szenario wo das wirklich vorkommen könnte?

Ich beobachte generell die Entwicklung von Asterisk die letzten 2 Jahre mit gemischten Gefühlen muss ich ehrlich gestehen. Man hat so das Gefühl das weniger Wert auf Stabilität und Ausbau der vorhandenen Features gelegt wird als ständig neue Features bzw. Versionen nachzuschieben. Das kann man schon an der Tatsache sehen das es einen aktiven 1.2, 1.4 und 1.6 Tree gibt von Asterisk.

Was mich zu meiner letzen Frage bringt (bei Deinem Mittelteil Zwecks Einsatz von Snom/Kirk sind wir nach vielen Tests zum gleichen Schluss gekommen ) die Du mir noch "schuldig" bist *grins* ist die Event Geschichte übers AMI Interface. Wie geht Ihr damit um das man im 1.2er bzw. 1.4er tree nicht alle Events bekommt um eine sinnvolle CTI Applikation bzw. Überwachung zu realisieren. Oder benötigen das Eure Kunden nicht?

gruss
sisko-m

 

[foschi]

Ich finde es halt etwas schade, um es freundlich zu umschreiben, das doch ein so grosser Markt wie Europa, wo ISDN ja flächendeckend im Einsatz, ist so wenig Berücksichtigung in Asterisk findet.
Dadurch lassen sich halt "ALL in ONE" Lösungen schwerlich umsetzen.

ISDN PRI (!) findet sehr wohl Beachtung, und Digium ist selbst bei ISDN BRI aufgewacht. Ich finde es allerdings aus Sicht von Digium verständlich, ISDN BRI nicht mit höchster Priorität zu beachten.

"All-in-one"-Lösungen sind bei Softswitches nicht notwendig (siehe Cisco und M$) und zwar "billig" aber strukturell IMHO keine gute Lösung. Die kleinen "A" der TK-Welt sind dafür besser geeignet. Asterisk macht eh erst ab einer gewissen Grösse oder Funktionsanforderung Sinn.

Was mich noch ein wenig umtreibt ist Dein Kommentar .. gäbe es denn da von Deiner Seite aus irgendein sinnvolles Szenario wo das wirklich vorkommen könnte?

Kartenbasierte Systeme mit eigenen oder stark modifizierten ISDN-Subsystemen machen z.B. da Sinn, wo per Q.SIG speziell adaptiert werden muss. Sowas leistet kein Herstellern von Mediengateways vor, da die Nische zu gering. Desweiteren gibt es ja auch Kartenlösungen für Fax, GSM und Callcenter-Anwendungen, die sich mittels eigenem Channel-Modul einbinden lassen, und die für die Allgemeinheit ebenfalls zu speziell sind. In diesen Bereichen ist es wirtschaftlich und funktional interessant, selbst die Schnittstelle steuern zu können.

Für alles andere ist die strukturelle Entkopplung von leitungsgebundenen Schnittstellen und Softswitches sinnvoll.

Man hat so das Gefühl das weniger Wert auf Stabilität und Ausbau der vorhandenen Features gelegt wird als ständig neue Features bzw. Versionen nachzuschieben.

Ich würde Asterisk nicht mit einer kommerziellen oder proprietären Software vergleichen. Grade dort (siehe Microsoft) wird über neue Funktionen die SW verkauft und die Qualität und Stabilität vernachlässigt.

Bei Asterisk baust Du Dir die Features die Du brauchst halt selbst. Kannst Du das nicht dann hast Du halt Pech gehabt, und musst mit dem leben was andere für Dich vorleisten. ;-)

Wie geht Ihr damit um das man im 1.2er bzw. 1.4er tree nicht alle Events bekommt um eine sinnvolle CTI Applikation bzw. Überwachung zu realisieren. Oder benötigen das Eure Kunden nicht?

Einen Teil der gewünschten Funktionen haben wir mit anderen Applikationen und den vorhandenen Events des Manager-IF realisiert. Für alles weitere warten wir bis es vielleicht in Asterisk vorhanden ist. Bei den an uns gestellten Anforderungen haben wir damit bisher keine Probleme (vielleicht Glück?) gehabt.

 

[Tweety]

Ich würde Asterisk nicht mit einer kommerziellen oder proprietären Software vergleichen. Grade dort (siehe Microsoft) wird über neue Funktionen die SW verkauft und die Qualität und Stabilität vernachlässigt.

Uha, das muss man wohl ganz differenziert betrachten. Qualität und Asterisk ist meiner Meinung nach etwas, was sich nicht immer gut verträgt. Man möchte sich doch nur mal das Entwicklungsmodell hinter Asterisk 1.6 anschauen - dazu gibt es ja feine Diskussionen auf der Mailingliste. Asterisk 1.4 hab ich mich nicht "getraut" vor 1.4.21.2 wirklich produktiv einzusetzen. Eigentlich sind wir ja bei 1.6 schon bei 1.6.9 ;-) nur ist die Bezeichnung etwas anders.

Wenn man wirklich professionell mit Asterisk VoIPen möchte (bzw. Kunden darauf basierende Lösungen anbieten möchte) sollte man wohl dringenst C können. Situationen bei denen es wirklich heftigst knallt kommen zwar nicht so oft vor (wenn man intern testet), lassen sich jedoch nicht ausschließen. Wenn der Asterisk dann tatsächlich steht oder alle 2-3 Telefonate abschmiert kommt man evtl. in gewisse Schwierigkeiten. Kann ich dann kein C und/oder hab kein Plan von gdb etc. und stelle dann einfach mal "dumm" bei Digium einen Bug ein - gute Nacht! Meistens fehlen dann selbst noch die Debugging Symbole.

Daher meine Best Practice: Vorher testen, testen, testen!!! und unter die Haube schauen, bevor man sich als 0815 Dienstleister, der mit viel Müh und Not auf der Windows Oberfläche zurecht kommt, auch noch VoIP bzw. noch schlimmer Asterisk ;-) einfängt. Es sind ja nun schon wirklich mehr als genug gescheiterte VoIP Projekte bekannt.

Zurück zum Anfang: Wenn ich mir etwas von einem "renomierten" Hersteller wie Cisco oder Microsoft kaufe gibt es je nachdem immer noch die "letzte Instanz", der Hersteller Support. OK! den gibts bei Asterisk auch, aber ob ich mich bei einem solch gemischten Umfeld (Patton, SNOM, Switche, etc.) darauf verlassen möchte?

Bei Asterisk baust Du Dir die Features die Du brauchst halt selbst. Kannst Du das nicht dann hast Du halt Pech gehabt, und musst mit dem leben was andere für Dich vorleisten. ;-)

Es ist doch so, dass vor allem der Endkunde bzw. der generelle Ruf der Lösung darunter leidet. Ich predige immer, dass Telefonie (egal bei welcher Unternehmensgröße) Mission Critical ist. Viele scheinen das einfach nicht zu kapieren und meinen, weil man nun einen Asterisk kompiliert und 2-3 Dateien editiert hat, könne man nun Anlagen mit mehreren hundert Nebenstellen aufstellen. SIP SDP RTP Q.931 Q.921?? Nie gehört! Warum auch, konnte doch auch so mit 2 Telefonen untereinander telefonieren.

 

[lucderheld]

Moin,

also ich persönlich habe vor etwa einem Jahr mit einer ganz normalen Asterisk 1.2 kompilation auf einem Suse System angefangen. Dieses Stand auf einem dedicated Server in irgendeinem Rechenzentrum. Dahmals ging es lediglich um eine Warteschleife die über Voip 6 plätze bietet und einen Agent bedient. Nach und nach sind dann ortsnetzrufnummern dazugekommen und ein weiterer Agent. Nach einem Umzug in eine neue Halle, wurden dann auch Telefone gekauft. Hier habe ich zwei Grandstream Telefone und drei Siemens C(wieviel auch immer) IP.
Da fingen die Probleme dann an. Mit NAT und gesprächsabbrücken einseitige Kommunikation etc. Als dann auch noch die ausenstelle mit einem Siemens C angebunden wurde war es schon fast eine Kathastrophe. Die Einrichung eines STUN, alles auf NAT=yes und canreinvite=no zu stellen hatte fast alle schwierigkeiten gelöst. Den Server dann direkt in die Firma zu holen und nicht mehr über das Internet zu betreiben ebenfalls einiges. Nur die sporadischen gesprächsabbrüche blieben. Konfiguriert habe ich jedoch trotzdem fast alles: Die lichter auf den Grandstream habe ich zum blinken, leuchten und farbenwechseln gebracht, anrufe holen war möglich, der attended transfer und der unattended transfer an jedem Telefon, Call parking und was es da sinst so alles gibt. Später als der Chef drängte (wegen den gesprächsabbrüchen) habe ich mir dahmals eine Starface Anlage angeschafft um auch gleichzeitig Voip durch ISDN zu ersetzen. Seitdem gibt es keine schwierigkeiten mehr.

Als ich vor einigen Monaten die Firma wechselte und erneut eine Telefonanlage installieren sollte, habe ich mich wiederholt für Asterisk entschieden. Diesesmal jedoch weil ich auch die konferenzraumfunktion dabeihaben wollte für "Asterisknow". Auch wenn ich hier eigentlich nur den Manuellen File-Editor benutze um etwas zu konfigurieren. Einfach nur um eine Linux Distri zu haben die einigermaßen auf Asterisk abgestimmt ist und ein Asterisk was mit allen Modulen die ich brauche kompiliert ist. Hier habe ich mir dann auf Forschis Anweisung hin weil ich ebenfalls hier ISDN haben wollte für ein Patton Smartnode entschieden. Nach 2 Tagen wirres konfigurationsdateizusammengeklau hier im Forum habe ich es auch tatsächlich zum funktionieren gebracht. Nun habe ich mir erneut einige Grandstream Telefone bestellt. Ich bin gespannt ob es diesesmal besser läuft . Das mit den gesprächsabbrüchen jedenfalls ist weg. Das einzige Problem was nun noch auftaucht ist das wenn mehr als ein Agent Anrufe beantworten nach einer gewissen Zeit der Agent einfach auf Busy stehenbleibt. Warum habe ich noch nicht herausgefunden. Wenn ich jedoch in meine queues.conf einfach schreibe er soll SIP/101 anrufen anstatt einen agent oder eben nicht mit addqueuemember arbeite tritt dies nicht auf. Aber das steht bereits in einem anderen Thread.

Ich möchte auf jedenfall weiter mit Asterisk arbeiten. Auch Starface hat mir sehr gefallen. Gerade die Möglichkeit alles Benutzerbasiert und nicht Telefon oder Rufnummernbasiert aufzubauen fand ich enorm praktisch. Dahin will ich mit meiner Installation auch noch kommen. :-Ö

 

[foschi]

@lucderheld: kleiner Tipp: Gemeinschaft. Individuell anpassbar, aber nix für Anfänger. Dafür auch keine Lizenzkosten wie bei Starface.

 

[KaMe]

Ich würde ausschliesslich die SN463x-Geräte benutzen (integriertes Netzteil, robustes Metallgehäuse, 19"-Option, +1 ISDN S0-Port für diverse Zwecke).

Ich habe mir den SN4639/5BIS/EUI angeschaut.

Meine Frage ist, ob es auch noch Gateways mit mehr als 5 Ports gibt oder ob diese dann kaskadiert werden?

Wie sieht es mit analogem Fax aus? Gibt es auch Modelle mit Analogport oder muss ich hier auch mit a/b Wandler arbeiten?

Wenn ich das Manual richtig verstanden habe, kann ich die Leitung direkt, also ohne NTBA dazwischen, an das Patton-Gateway anschließen. ist das so korrekt?

Die 19" Option von der du gesprochen hast habe ich leider nicht gefunden.
Wie heißt diese Option genau?

@lucderheld: kleiner Tipp: Gemeinschaft. Individuell anpassbar, aber nix für Anfänger. Dafür auch keine Lizenzkosten wie bei Starface.

ich habe mir Gemeinschaft einmal flüchtig angeschaut.
ich finde die Herangehensweise ziemlich cool. (Provisioninh, Hot Desking,...)

Allerdings gab es einen Dämpfer, als ich versucht habe das ISO auf einer Hardware-Büchse (IBM X3200 M2) zu installieren (Davor VM).
Das Setup erkennt keine SATA-CDROMs,...

Installierst du die Gemeinschaft über das ISO oder installierst du die Packages auf einer Linuxbasis deiner Wahl?

 

[foschi]

Meine Frage ist, ob es auch noch Gateways mit mehr als 5 Ports gibt oder ob diese dann kaskadiert werden?

Es muss nichts kaskadiert werden, man verwendet einfach mehrere Geräte gleichzeitig.

Wie sieht es mit analogem Fax aus? Gibt es auch Modelle mit Analogport oder muss ich hier auch mit a/b Wandler arbeiten?

Es gibt Modelle mit analogen Ports, z.B. die SN411x-Reihe, die per T.38 direkt mit dem Medien-GW am Amt genutzt werden können.

Wenn ich das Manual richtig verstanden habe, kann ich die Leitung direkt, also ohne NTBA dazwischen, an das Patton-Gateway anschließen. ist das so korrekt?

Ich versteh' die Frage nicht.

Die 19" Option von der du gesprochen hast habe ich leider nicht gefunden.
Wie heißt diese Option genau?

Diese Option heisst "19"-Option", und es gibt sie für die SN46XX- und SN496X-Reihe.

Allerdings gab es einen Dämpfer, als ich versucht habe das ISO auf einer Hardware-Büchse (IBM X3200 M2) zu installieren (Davor VM).
Das Setup erkennt keine SATA-CDROMs,...

Ich habe auch nie davon gesprochen, irgendein (warscheinlich nicht sauber funktionierendes) ISO-Image zu nutzen.

Installierst du die Gemeinschaft über das ISO oder installierst du die Packages auf einer Linuxbasis deiner Wahl?

Letzteres. Wir haben eigene Pakete.

 

[foschi]

Diesesmal jedoch weil ich auch die konferenzraumfunktion dabeihaben wollte für "Asterisknow".

AsteriskNOW hat noch einen langen Weg vor sich, ist aber besser geworden in den letzten Jahren. Es fehlt aber einiges, was z.B. TrixBox oder Gemeinschaft bereits haben. Ich würde inzwischen immer nur Gemeinschaft (im deutschsprachigen Raum) nutzen.

Hier habe ich mir dann auf Forschis Anweisung hin weil ich ebenfalls hier ISDN haben wollte für ein Patton Smartnode entschieden. Nach 2 Tagen wirres konfigurationsdateizusammengeklau hier im Forum habe ich es auch tatsächlich zum funktionieren gebracht.

Nicht sehr wirtschaftlich ;-) Normalerweise dauert die Konfig einer SmartNode in komplizierten Fällen 1-2h.

Nun habe ich mir erneut einige Grandstream Telefone bestellt. Ich bin gespannt ob es diesesmal besser läuft .

Ich würde *nie* Grandstream-Geräte für den professionellen Einsatz nutzen wollen. Grandstream ist um Jahre hinter snom, Polycom oder Siemens in Sachen Qualität (Hard- und Software) hinterher. Grandstream ist billig, das ist alles.

Gerade die Möglichkeit alles Benutzerbasiert und nicht Telefon oder Rufnummernbasiert aufzubauen fand ich enorm praktisch. Dahin will ich mit meiner Installation auch noch kommen. :-Ö

Dann solltest Du Dir mal das anschauen was andere schon längst nutzen