Gemeinschaft PBX

[Bjoerneee]

Hallo Freunde der Kommunikation, 
mich würde es interessieren, ob einer von euch schon Erfahrungen mit dem Gemeinschaft PBX gemacht hat?!

Für alle die mit Gemeinschaft noch so garnichts anfangen können, ist vielleicht dieses Video auch ganz interssant! (Auf dem Kanal finden sich auch viele Interessante andere Sachen über Gemeinschaft!)

lg Björn 

[8818freak]

ich versuche mich gerade daran, aber ich kenne leider kein linux und derzeit scheitere ich noch sehr kläglich. ich bekomme nicht mal eine diva 4 bri-8 als nebenstellenanschluß eingerichtet... 
ansonsten wirkt das ganz nett. ich bin nur kein freund von voip und dergleichen, das werde ich also nicht nutzen...

[reini5555]

Es ist halt eines der vielen open sorce Projekte,
und egal welche man betrachtet, stimmt nur das I Tüpfelchen auf der Hardware nicht, kann man sich nur die Haare ausraufen. Zum ernsthaft telefonieren sind die nicht geeignet.
Es fängt damit an, Linux ist ein offenes Betriebssystem, jeder kann sich einbringen, hört sich toll an, aber genau das ist der große Nachteil, man weis nie was bei welcher Version noch geht. Ich hatte bis vor einiger Zeit privat selbst einen Linuxserver am laufen, aber irgendwann ging kein AVM USB W lan stick mehr, AVM hat nach all dem Chaos als noch einzig verbliebener großer Hersteller den Support vor 2 Jahren eingestellt.
Und wenn man so was einen PC nicht mal mit jeder Hardware zum laufen bringt, wie soll dann Telefonie noch richtig laufen?
Selbst die TK Anlagen Hersteller welche ein Linux basierendes System haben, tun sich beim wechseln der neuen Release schwer, es kommen meist kurz darauf neue Unterrleases heraus. Und gerade der Hersteller hat je gegenüber dem Homebasteler den Vorteil, es ist angepasste Hardware, er hat nicht verschiedene Chipsätze, oder Kartenfirmwares, und es steckt jede Menge an Manpower dahinter, und trotzdem funktioniert jede Release erst nach unzähligen Nachbesserungen.
Solche Soft PBXen sind auf den erstren Blick für den Errichter finaziell verlockend, aber es nützt nichts wenn man dann selbst jeden zweiten Tag vor beim Kunden verbringen würde, nur um wieder Fehler auszumerzen. Ganz zu schweigen von den zu erwarteten Schadenersatzansprüchen, vom Kunden, wegen Ausfall und damit Verdienstausfall. Ist also ein heißes Eisen, wo man sich als seriöser Techniker beim Kunden mit so was fernhalten sollte.

[8818freak]

nun, mir gehts um mich hier zu hause. ich benötige eine umsetzung von mehrgeräteanschluß auf anlagenanschluß und zurück, bei der handies mitklingeln können, die mein vm und meinen faxserver ersetzt und die den nst abgehend die richtige msn zuordnet. und das kann eine hipath beispielsweise nicht.

[telthies]

Ich hatte bislang noch keine Ambitionen, mir mal quasi aus Jux eine Testinstallation von Gemeinschaft "hinzustellen". Den Amooma-Gründer Stefan Wintermeyer kenne ich persönlich seit zwanzig Jahren, damals war er schon jemand, den das ambitionierte Anwenden des 1TR6-ISDN quasi dahin gezwungen hat, sich umfassend selbst mit den technischen Möglichkeiten zu beschäftigen. Nach reichlich Erfahrung als Anwender der TeleS iPBX war er u.a. für Support zuständiger Vice President beim Linux-Developer SuSE. Wir teilen die Grundüberzeugung Open Source. Stefan erwartet von einem Gebrauchsprodukt umfassende Tauglichkeit und Zuverlässigkeit, sowie daß es seinem Anwender stets verständlich ist und dafür offen ist, von ihm (also auch dem einfachen, nicht zwingend studierten Anwender) seinen Bedürfnissen entsprechend weiterentwickelt zu werden. Mit Quality of Service hat er sehr wenig Humor und weist daher auch stets darauf hin, ISDN-Amtsköpfe nicht bei Billigheimern zu kaufen. Daher stützt sich das Produkt "Gemeinschaft" auf die Erfahrung aus beiden Welten (im Sinne von TK und IT wie im Sinne von ISDN und VoIP). D.h. dieses Produkt kommt nicht aus der Schmiede eines VoIP-Heilspredigers, sondern spiegelt den gegenwärtigen Stand der entwicklerischen Bemühungen darum, die genannten Anforderungen bestmöglich zu erfüllen.

[reini5555]

Ich hatte bislang noch keine Ambitionen, mir mal quasi aus Jux eine Testinstallation von Gemeinschaft "hinzustellen".

Na so was macht man nicht aus Jux, sondern halt zum testen, wie ausgereift ist dieses und jenes. Ist ein Teil Freihzeit, wechlen man für berufliche opfert, aber damit lernt man erst die Tücken kennen.
 

Mit Quality of Service hat er sehr wenig Humor und weist daher auch stets darauf hin, ISDN-Amtsköpfe nicht bei Billigheimern zu kaufen.

Ist zwar ein guter Hinweis, aber es nützt wenig, wenn das Gesamtpaket dann doch nicht zusammenpasst. Für die PC Bastler und Krattler ist es ein Segen, sich beliebig alles zusammenzustellen und zusammenstecken.
Wie war das noch vor ein paar Jahren, Nvida und AMD, beide waren nicht schlecht, doch zusammen in einem PC Gehäuse gabs Abstürtze. Das war damals ein krasser Fall, der selbst dem Enduser aufgefallen ist, aber bei weitem kein Einzelfall, nur treten manche Probleme nur bei einer Anwendung auf. Und keiner Normalo hat ein Testlabor, wie ein bekannter Hersteller von Lichrufsystemen, der sich immer wenn eine Kombi aus Einzelteilen erfolgreich die Tests bestanden hat, der er sich gleich einen 3 Jahres Vorrat an den Komponenten auf Lager legt, und dabei schon wieder die nächsten Zusammenstellungen sucht.
Ich war mal bei einem Kopiererhersteller auf Lehrgang, und wie sagte dort ein Entwickler so schon, die Welt könnte so einfach sein, wenn wir Einheitshardware bei den PC hätten.

[telthies]

Ich hatte bislang noch keine Ambitionen, mir mal quasi aus Jux eine Testinstallation von Gemeinschaft "hinzustellen".

Na so was macht man nicht aus Jux, [...]

Ich meinte damit, mir eine Testanlage einfach nur so hinzustellen. Ich bin ja freier Fachjournalist und Berater, kein Verkäufer und Einrichter. Deshalb habe ich schon Interesse am Kennen des Alltagsverhaltens der diversen Produkte innerhalb meines Faches, aber keinen in Haftungsgründen liegenden Drang nach Tests und auch kein Labor. Wenn ich ein Produkt testen will, kann ich das nur in meinem Alltag tun (wo es natürlich Anlage und Endgeräte bereits gibt). Ein Quasi-"Konkurrenz"-Produkt zu den Komponenten meines Bedarfes danebenzustellen, das eigentlich benutzte auszustöpseln und das kennenzulernen begehrte statt seiner einzustöpseln, nur um es einmal im Gebrauch beurteilen zu können, das wäre in dieser Situation eben Jux.

[reini5555]

Ich bin ja freier Fachjournalist und Berater, kein Verkäufer und Einrichter.

Klar ist das Testen ja eher für Errichter,
oder auch dann wenn man für die Technik verantwortlich ist. Zumal ich ja dann die Anlage erst mal am Wochenende zuhause, meinem privaten Streßtest unterziehe, geht der dan schalte ich die zwei NTBAs von der innerbetrieblichen Technikernummer auf die Testanlage, wo 6 Endgeräte draufgeschalten werden (Auf dieser Nummer rufen die Leute auf der Baustelle, die Partner wo mal Support brauchen, und die Lieferanten an).
Denn so kann man die eigenen Erfahrungen bringen, was die Leute dann an Feedback bringen. Und bekanntlich sind die eigenen Kollegen die größten Kritiker, da wird manchmal das kleinste Haar in der Suppe bemängelt, aber das kann man ja ausfiltern.
Denn selbst man 2 Premiummarken im Portfolio hat, kann es nie schaden, das man auch über den Tellerrand hinausschaut. Ich verstehe auch die Errichter nicht, wo sich nur mit einer Marke befassen, und wenn man sich mit denen dann Unterhält, kommt von derer Seite oft ein Staunen, und der Spruch " nö die Funktionen oder Möglichkeiten kenn ich gar nicht".
Ich erlebe ja immer wieder, wie ein Hersteller plötzlich seine Geschäftspolitik ändert, verkauft wird, usw.. Und dann steht man vor einem Scharbenhaufen, wenn man nicht weis, was nehme ich jetzt. So passierte es einigen kleineren Errichtern die mit EADs telekom sehr gut klarkamen, durch die Übernahme/ Fussionierung mit Aastra, der Status wurde heruntergestuft, dadurch wurden die Einkaufskonditionen schlechter, der Support war nur noch über einen 0900er Nummer für die erreichbar (so gaben sich die net-vance Partner gegenseitig notgedrungen Support, denn mein ex Chefe hatte ja noch Gold Status).
Aber befriedigend war es für die Jungs nicht, und jeder derer war dann auch der Suche, und Firmen mit 1-5 Mitarbeitern haben nun mal nicht das Umsatzvolumen, wo sich die Hersteller die Klinke geben.

[Koppelfeld]

als Anwender der TeleS iPBX war er u.a. für Support zuständiger Vice President beim Linux-Developer SuSE.

Ah, Danke für die Information, daher weht also der Wind.

Ich habe mir das Konglomerat mit dem gleichen Entsetzen
und dem gleichen Ekel angeguckt die beispielseweise
"SuSE" und "KDE".  Diese "aufgemotzten" Pakete versu-
chen krampfhaft und vor allem krankhaft, UNIX zu "zähnen"
und "anwenderfreundlich" zu machen.
Da gibt es Läden, die können das, zum Beispiel Äppel.
Und da gibt es "gewollt und nicht gekonnt", aber mit viel
GUI, LDAP, JAVA, AJAX, XML etc..
Da ist nicht mehr die Mantabastler-Mentalität, das ist
"optisches Tuning", das in der gleichen Lächerlichkeits-
liga dilettiert wie Westerwelle.

Ich gebe ja "reini555" nur ungern recht, aber sowas setzt
man nicht für unternehmenskritische Anwendungen ein.
Kollege Marowsky-Brée meinte mal im Usenet, "Feuern
nach eigenem Ermessen" sollte zum Adminjob dazuge-
hören, aber im Gegensatz zu "reini" würde ich nicht so
eine OA-15 einsetzen, sondern eine Heckler&Koch MP5.
Die gibt es schon ab Werk fertig eingebaut in einem
neutralen Diplomatenköfferchen mit Abzug im Griff.
Nix "Maus", DAS ist das ultimative Point - and Click -
Interface.

WENN man eine solide Technik aufbauen will, dann
besorgt man sich eine solide Linux-Distribution, instal-
liert das mitgelieferte Asterisk und konfiguriert es nach
guter Väter Sitte selber.

So haben wir das gemacht, so läft es bei uns mit mitt-
lerweile 400 Ports und jeder Menge Schribbelschrab-
bel an etlichen Standorten mit unterschiedlichsten
Endgeräten ohne Probleme und das ganze auch noch
hochverfügbar - sauber integriert in unser AS/400 und
komplett Windows- und virenfrei.
Das kriegt man mit den "Premium-Herstellern" in dieser
Klasse und Leistung meines Wissens nicht hin, wie "reini"
leider gesagt werden muß.

[Koppelfeld]

nun, mir gehts um mich hier zu hause. ich benötige eine umsetzung von mehrgeräteanschluß auf anlagenanschluß und zurück, bei der handies mitklingeln können, die mein vm und meinen faxserver ersetzt und die den nst abgehend die richtige msn zuordnet. und das kann eine hipath beispielsweise nicht.

Patton-Gateway.  Z.B. 3 x BRI jeweils einstellbar als NT/TE und PP/PMP, 1xLAN für VoIP.
Kannst Du selektiv alle umrouten, Dienstemerkmale ändern, presentation indicator ändern
etc.  Das Schweizer Taschenmesser für ISDN.

Kann ich Dir einen zum Ausprobieren ausborgen, habe noch einen 4554 mit zwei Ports 'rumfliegen.

[mmg]

WENN man eine solide Technik aufbauen will, dann
besorgt man sich eine solide Linux-Distribution, instal-
liert das mitgelieferte Asterisk und konfiguriert es nach
guter Väter Sitte selber.

und das ist "gemeinschaft" auf debian basierend nicht?

[Koppelfeld]

WENN man eine solide Technik aufbauen will, dann
besorgt man sich eine solide Linux-Distribution, instal-
liert das mitgelieferte Asterisk und konfiguriert es nach
guter Väter Sitte selber.

und das ist "gemeinschaft" auf debian basierend nicht?

Gutes Beispiel - klare Antwort:  NEIN.
Das unter Debian mitgelieferte Asterisk hat seit gut einem Dreivierteljahr einen
ekligen deadlock-Bug bei Verwendung von BLF-Hints.  In diesem Falle ist
wie so oft ein Deadlock der heimtückische Bruder des Crashs:  Nach einem Crash
kann man untersuchen und neu starten, beim Deadlock ist das schwierig - vor
allem für die, die telephonieren wollen.
Gut, "reini" mag unsachlich sein, aber hier stoße ich ins gleiche Horn:  In der
Frickelgarage mit zwei Telephonen fällt das nicht auf, aber wir haben ein paar
hundert registrierte hints und noch mehr korrespondierende subscriptions.
Da ist ganz schön 'was los, wenn viel telephoniert wird.

Debian leistet gute Arbeit, wenn es um security updates geht, liefert aber gern
ziemlich alte Softwarestände aus, deren Betriebssicherheit zu wünschen übrig
läßt.

Ich gehe 'mal davon aus, daß wir uns darüber einig sin, daß eine größere VoIP-
Anlage nicht hinter einem NAT/NAPT sitzen sollte.  SIP/RTP sorgt bei jedem Fire-
wall-Admin sowieso für nässenden Ausschlag, ebenfalls aus bekannten Gründen.

Auf eine exponierte Kiste setze ich ganz sicher keine LAMP-Applikation auf mit
drei richtig gefährlichen Büchsenöffnern:  Apache, MySQL und PHP.
Hier gilt, ganz allgemein:  Das Konfigurations- und Serviceinterface muß von der
operativen Einheit striktestens getrennt sein.  --> SCADA, stuxnet.

Noch ein Argument gefällig:
Zitat von der Webseite:
| Es ist unmöglich eine Firma und die dahinter stehende Philosophie in ein paar
| Sätzen zu beschreiben. Sie stehen vielleicht vor der Entscheidung welche Firma
| Sie für ein wichtiges Consultingprojekt beauftragen sollen und suchen hier noch
| Argumente.
Genau.  Ein Softwareentwickler, der in zwei Sätzen zeigt, daß ern nicht einmal
mit einer vergleichsweise einfachen Grammatik klarkommt, käme für mich nicht
infrage.

Das Hauptproblem bei Projekten wie "Gemeinschaft" ist der Ansatz, eine 'one fits
all' - Lösung schaffen zu wollen, die ibs. mit den unterschiedlichsten Periperiegerä-
ten systemkonform zusammenarbeiten soll.  Das ist ein gefühltes O(n³) - Problem.

Vor allem:
Es geht auch anders.  Was spricht gegen ein einfaches Programmsystem, welches
aus Metadaten, die sich aus der Anforderung ergeben, die entsprechenden Konfigu-
rationsdateien für Asterisk resp. die eingesetzten Clients und Gateways generiert ?

Small is manageabe.

[reini5555]

eine OA-15 einsetzen, sondern eine Heckler&Koch MP5.
Die gibt es schon ab Werk fertig eingebaut in einem
neutralen Diplomatenköfferchen mit Abzug im Griff.
Nix "Maus", DAS ist das ultimative Point - and Click -
Interface.

Nö sorry, die HK MP5 gibt es so nur in schlechten Filmen, und utimativ ist so eine 9mm Plüste mit gerade nicht mal 500 Joule E0, gegenüber einer .223 im 1800 Joule E0 bestimmt nicht. Zumal man mit dem legelem Besitz einer MP5 in privater Hand wohl ein kleines Problem hätte.

Das kriegt man mit den "Premium-Herstellern" in dieser
Klasse und Leistung meines Wissens nicht hin, wie "reini"
leider gesagt werden muß.

Aber erzähl mal was da nicht gehen soll (man muss auch die Herstellerschulungen mal besuchen)?
400 NST sind eher Mittelmaß, das stellt für niemand eine Herausforderung. Wir schon in einem anderem Tread mal erwähnt wurde, wird es erst richtig spannend, jenseits der 5000er Marke, das wird es dann dünn.

[mmg]

Gutes Beispiel - klare Antwort:  NEIN.
Das unter Debian mitgelieferte Asterisk hat seit gut einem Dreivierteljahr einen
ekligen deadlock-Bug bei Verwendung von BLF-Hints.  

lenny (1.4) oder squeeze (1.6)? und gemeinschaft nutzt davon abgesehen meines wissens nach nicht die debian pakete von asterisk.

hast du da mal einen link zum bugreport für mich? im debian bugtracker konnte ich nichts derartiges finden (http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=asterisk)

Gut, "reini" mag unsachlich sein, aber hier stoße ich ins gleiche Horn:  In der
Frickelgarage mit zwei Telephonen fällt das nicht auf, aber wir haben ein paar
hundert registrierte hints und noch mehr korrespondierende subscriptions.
Da ist ganz schön 'was los, wenn viel telephoniert wird.

da dürften wir einer meinung sein - hat allerdings auch keine relevanz im bezug auf debian oder gemeinschaft.

Debian leistet gute Arbeit, wenn es um security updates geht, liefert aber gern
ziemlich alte Softwarestände aus, deren Betriebssicherheit zu wünschen übrig
läßt.

wie passt das denn zusammen? security updates gut, betriebssicherheit schlecht? was verstehst du denn unter betriebssicherheit?

Ich gehe 'mal davon aus, daß wir uns darüber einig sin, daß eine größere VoIP-
Anlage nicht hinter einem NAT/NAPT sitzen sollte.  SIP/RTP sorgt bei jedem Fire-
wall-Admin sowieso für nässenden Ausschlag, ebenfalls aus bekannten Gründen.

sip selbst ist nicht das problem, nicht mal für firewall-admins. rtp ist kritisch und daran scheitern viele. allerdings wäre das für mich immer noch kein grund, eine pbx grundsätzlich in ein ungeschütztes segment zu hängen. der (meistens) richtige standort dafür ist eine dmz. ausnahmen ausgenommen ;-).

Auf eine exponierte Kiste setze ich ganz sicher keine LAMP-Applikation auf mit
drei richtig gefährlichen Büchsenöffnern:  Apache, MySQL und PHP.
Hier gilt, ganz allgemein:  Das Konfigurations- und Serviceinterface muß von der
operativen Einheit striktestens getrennt sein.  --> SCADA, stuxnet.

wie so oft: der teufel steckt im detail. wenn die dienste richtig konfiguriert sind, sind sie auch sicher. auf den meisten linux webservern da draussen, und davon gibt es viele, läuft ein LAMP stack. die, die gehackt werden, sind in der regel die mit veralteten paketen oder zu unsicher konfigurierten diensten. ein mysql muss nicht auf die öffentliche ip hören und auch ein apache/php ist in der regel sicher, wenn man die scheunentore nicht selbst öffnet.

auch hier sehe ich keinen zusammenhang mit debian oder gemeinschaft.

Noch ein Argument gefällig:
Zitat von der Webseite:
| Es ist unmöglich eine Firma und die dahinter stehende Philosophie in ein paar
| Sätzen zu beschreiben. Sie stehen vielleicht vor der Entscheidung welche Firma
| Sie für ein wichtiges Consultingprojekt beauftragen sollen und suchen hier noch
| Argumente.
Genau.  Ein Softwareentwickler, der in zwei Sätzen zeigt, daß ern nicht einmal
mit einer vergleichsweise einfachen Grammatik klarkommt, käme für mich nicht
infrage.

mir wäre wichtiger, dass der softwareentwickler etwas vom software entwickeln versteht als von grammatik.

Das Hauptproblem bei Projekten wie "Gemeinschaft" ist der Ansatz, eine 'one fits
all' - Lösung schaffen zu wollen, die ibs. mit den unterschiedlichsten Periperiegerä-
ten systemkonform zusammenarbeiten soll.  Das ist ein gefühltes O(n³) - Problem.

das verstehe ich irgendwie anders. gemeinschaft ist, so verstehe ich es, eher eine basis, auf der man seine konkrete implementierung aufsetzen kann. ich kann mich aber irren. wir hatten uns gemeinschaft angeschaut, für uns hat's nicht gepasst, also haben wir's verworfen - allerdings nur für uns. deshalb muss gemeinschaft noch lange kein schlechtes projekt sein oder einen falschen ansatz verfolgen.

Vor allem:
Es geht auch anders.  Was spricht gegen ein einfaches Programmsystem, welches
aus Metadaten, die sich aus der Anforderung ergeben, die entsprechenden Konfigu-
rationsdateien für Asterisk resp. die eingesetzten Clients und Gateways generiert ?

Small is manageabe.

weil's in der regel gefrickelt ist. die meisten systeme dieser art hängen an einem einzigen entwickler. hat der keine lust mehr, stirbt das projekt. in abhängigkeit von komplexität ist danach neuentwicklung angesagt - vielleicht auch nur, weil der nächste betreuer andere ideen hat, es noch einfacher haben möchte oder dinge vermisst und die verwendeten scripts nicht durchschaut. warum auch immer. been there - done that. kiss ist schön - muss aber gewissen grundsätzlichen anforderungen folgen. und das bedeutet für mich beispielsweise, dass manageable sich nicht nur auf eine person bezieht.

vg
Marco

(edit: kleinigkeiten)

[Koppelfeld]

Gutes Beispiel - klare Antwort:  NEIN.
Das unter Debian mitgelieferte Asterisk hat seit gut einem Dreivierteljahr einen
ekligen deadlock-Bug bei Verwendung von BLF-Hints.  

lenny (1.4) oder squeeze (1.6)? und gemeinschaft nutzt davon abgesehen meines wissens nach nicht die debian pakete von asterisk.

hast du da mal einen link zum bugreport für mich? im debian bugtracker konnte ich nichts derartiges finden (http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=asterisk)

Die Debianisten haben den gar nicht mitgekriegt:
https://issues.asterisk.org/view.php?id=18165
Der hat mich Nerven gekostet.  Zog sich sehr schön durch 1.6 und 1.8.

Gut, "reini" mag unsachlich sein, aber hier stoße ich ins gleiche Horn:  In der
Frickelgarage mit zwei Telephonen fällt das nicht auf, aber wir haben ein paar
hundert registrierte hints und noch mehr korrespondierende subscriptions.
Da ist ganz schön 'was los, wenn viel telephoniert wird.

da dürften wir einer meinung sein - hat allerdings auch keine relevanz im bezug auf debian oder gemeinschaft.

Stimmt, habe ja auch den entscheidenden Satz vergessen:  Erst im heftigen Echt-
betrieb, aber nicht in der Frickelbude treten die heimtückischen Fehler auf.

Debian leistet gute Arbeit, wenn es um security updates geht, liefert aber gern
ziemlich alte Softwarestände aus, deren Betriebssicherheit zu wünschen übrig
läßt.

wie passt das denn zusammen? security updates gut, betriebssicherheit schlecht? was verstehst du denn unter betriebssicherheit?

Da sind die Amis ausnahmsweise sprachlich differenzierter und unterscheiden
zwischen 'safety' und 'security'.  Betriebssicherheit, Robustheit, Zuverlässigkeit
versus Anfälligkeit gegen Sabotage.

Ich gehe 'mal davon aus, daß wir uns darüber einig sin, daß eine größere VoIP-
Anlage nicht hinter einem NAT/NAPT sitzen sollte.  SIP/RTP sorgt bei jedem Fire-
wall-Admin sowieso für nässenden Ausschlag, ebenfalls aus bekannten Gründen.

sip selbst ist nicht das problem, nicht mal für firewall-admins. rtp ist kritisch und daran scheitern viele. allerdings wäre das für mich immer noch kein grund, eine pbx grundsätzlich in ein ungeschütztes segment zu hängen.

Ich habe nichts Gegenteiliges behauptet.  Und auch unsere Asterisk hängt in einer
extra dafür eingerichteten DMZ.  Aber auch dort ist sie exponiert.  Sehr schön für
den Firewall-Admin ist auch die Kombi SIP / T.38 - reinvite.

wie so oft: der teufel steckt im detail. wenn die dienste richtig konfiguriert sind, sind sie auch sicher.

Das allerdings ist kaum zu schaffen und kaum noch zu auditieren.  PHP und MySQL
können im "Zusammenspiel" schon sehr garstig sein ("sql injection").

auch hier sehe ich keinen zusammenhang mit debian oder gemeinschaft.

Was nicht da ist, wird nicht zum Ärgernis.

mir wäre wichtiger, dass der softwareentwickler etwas vom software entwickeln versteht als von grammatik.

Dass korrespondiert erstaunlich.  Softwareentwicklung ist zu 0,3% Genialität,
zu 10% Ingenieursarbeit, zu 29,7% Handwerk und zu 60% Sorgfalt.

das verstehe ich irgendwie anders. gemeinschaft ist, so verstehe ich es, eher eine basis, auf der man seine konkrete implementierung aufsetzen kann. ich kann mich aber irren. wir hatten uns gemeinschaft angeschaut, für uns hat's nicht gepasst, also haben wir's verworfen - allerdings nur für uns. deshalb muss gemeinschaft noch lange kein schlechtes projekt sein oder einen falschen ansatz verfolgen.

Das eigentliche 'Telephonie-Framework' ist ja Asterisk; "Gemeinschaft" hat, so
habe ich es gesehen, erhebt den Anspruch, eine Telephonanlage zu sein.

\[...\]kiss ist schön - muss aber gewissen grundsätzlichen anforderungen folgen. und das bedeutet für mich beispielsweise, dass manageable sich nicht nur auf eine person bezieht.

Das sehe ich jetzt als äußerst schlicht gestrickter Mensch ganz anders:
Seit Jahren tut mir und meinen Kunden Patrick Powells 'lprng' gute Dienste, nicht
um alles in der Welt würde ich es gegen 'CUPS' eintauschen wollen, das von einer
großen "Communuty" gepflegt wird.  Aber ich bin ja auch so pervers und ziehe
Gerd Dörings "mgetty/sendfax" der Community-Lösung "Hylafax" vor.