Asterisk 1.2-final geeignet für ein produktives System ?

[o_dapenguin]

Hallo,
nachdem ich hier zum Stammleser geworden bin und mithilfe vieler sehr interessanter Beiträge ( thx ) hier mein Testsystem (1.0.9) zum geplanten Asterisk als PBX in einem Businessgebäude unter SuSE 9.3 zum Laufen bekommen habe, verging mir zum Schluss beim Zusammenschustern des Dialplans mehr und mehr die Lust, da für Mitte September das Release von Asterisk 1.2 angekündigt war. Die kommenden Änderungen, v.a. solche Dinge wie Attended Transfer und die Realtime Architektur bei hoffentlich guter Stabilität des Systems (neidvoller Blick auf Guard-X mit einem laufenden System von >= 150 SIP-Clients) wären bei dem geplanten Projekt, das bis Anfang November lauffähig sein soll, essentiell.

Meine Frage nun an die Betatester unter Euch: Stabil ? Wird das Release für produktive Systeme schon zu gebrauchen sein ? Oder sollte ich lieber die Finger davon lassen ? Wie sehr wird sich die Syntax des Dialplans ändern ? Last but not least: Weiß jemand, wann denn nun die endgültige Freigabe einer 1.2stable erfolgt ?

Danke

o_dapenguin

 

[Maik]

Es gibt bereits viele Produktivsysteme, die auf CVS-Versionen stabil laufen. Ich setze z.B. bei allen Systemen ausschliesslich CVS-Versionen ein. Man sollte aber, wenn man mal eine lauffähige Version hat, nur dann Updates einspielen, wenn ein Änderung enthalten ist, die man braucht. Bei den CVS-Versionen kann sich halt noch einiges ändern. Das könnte dann dazu führen, dass man an der Config was ändern müsste und das ist bei Produktivsystemen nicht so schön.

Im Moment gibt es aber nur sehr wenige Änderungen dieser Art, weil man halt hauptsächlich nur noch Bugfixes ins CVS aufnimmt, weil ja bald 1.2 erscheinen soll.

BTW: Das 'stable' bei der 1.0er bezieht sich übrigens nicht darauf, dass diese Version absolut stabil läuft sondern eher darauf, dass sich an den Features nichts mehr ändert. Man kann also zwischen 2 1.0.x-Versionen wechseln, ohne dass man was an der Config ändern müsste. Das wird bei 1.2 genauso sein.

Wan 1.2 jetzt genau erscheinen wird, weiss z.Zt. übrigens noch niemand. Ich hoffe aber dass es zumindest bald ne beta2 geben wird.

 

[Netview]

1.2.0beta1 läuft bei mir seit dem Erscheinungstermin absolut stabil und die Anpassungen der Konfigurationdateien halten sich auch in Grenzen!

 

[o_dapenguin]

@Maik
Das hört sich alles sehr vielversprechend an. In welcher Größenordnung bewegen sich Deine Systeme ? An welcher Stelle ist * jeweils im Einsatz ?

Grüße

p_dapenguin

 

[Guard-X]

@o-dapenguin,

neidvoller Blick auf Guard-X mit einem laufenden System von >= 150 SIP-Clients

Meine Frage nun an die Betatester unter Euch: Stabil ? Wird das Release für produktive Systeme schon zu gebrauchen sein ? Oder sollte ich lieber die Finger davon lassen ? Wie sehr wird sich die Syntax des Dialplans ändern ?

Ich werde in ca. 2-3 Wochen auf 1.2 umschwenken (vorerst auf einem Testsystem), dann kann ich auch was zu dem Thema sagen. Übringens: die 150 SIP Telefone sind gar nicht soviel wie es aussieht. Den größten Ballast bringt die Vernetzung der herkömmlichen TK-Anlagen. Die Anzahl liegt zur Zeit bei ca. 6 - 10.000 Gesprächen pro Tag.

@maik

Ich setze z.B. bei allen Systemen ausschliesslich CVS-Versionen ein.

CVS war bei meinem System leider schon mal der Tod, das Problem liegt immer bei den anderen Komponenten, die bei Asterisk Änderungen nicht immer ganz so schnell nachkommen.

mfg Guard-X

 

[Maik]

@Maik
Das hört sich alles sehr vielversprechend an. In welcher Größenordnung bewegen sich Deine Systeme ? An welcher Stelle ist * jeweils im Einsatz ?

Ich geb mal 2 Beispiele:
1) Ein Server zwischen TK-Anlage und Telekom zur Standortvernetzung. Ander TK-Anlage haengen ca. 1000 Nebenstellen.
2) Signalisierungs-Server für bisher ca. 60 Telefone.

Beide Systeme laufen bisher ohne Ausfälle (bei 2 z.B. seit ca. 150 Tagen).

CVS war bei meinem System leider schon mal der Tod, das Problem liegt immer bei den anderen Komponenten, die bei Asterisk Änderungen nicht immer ganz so schnell nachkommen.

Ich verwende nur sehr selten externe Komponenten und wenn dann auch nur die, die ohne Patches auskommen. Das macht das ganze viel einfacher und auch stabiler. Sowas wie Bristuff ist IMO eher ne Spielerei für den Privatanwender aber nicht für den Einsatz bei größeren Installationen geeignet.

 

[o_dapenguin]

Die Anzahl liegt zur Zeit bei ca. 6 - 10.000 Gesprächen pro Tag.

... meine Fresse ... oh, tschuldigung, aber da wird der neidische Blick noch von einem Hauch Bewunderung verklärt ... Ihr macht mir Hoffnung, dass die von mir favorisierte Lösung realistisch ist. Wäre der Spass am Selbercoden und Lösungen überlegen nicht so groß, dann hätte ich gesagt: Kauft Euch ne neue Telefonanlage ... aber das Argument, dass es mit * nicht mehr um die Frage geht: "Was kann denn die Anlage ?", sondern vielmehr die Gegenfrage interessiert: "Was soll sie denn können ? Machbar ist (fast) alles !" hat mich zu dem Einstieg in die Materie bewogen, wo ich bisher lediglich mit der Administration im DV-Serverbereich unter Linux beschäftigt war.
Ich bin gespannt und warte also (zumindest) auf die beta2.

Sowas wie Bristuff ist IMO eher ne Spielerei für den Privatanwender aber nicht für den Einsatz bei größeren Installationen geeignet.

Sag mir bitte, dass 30-40 interne Clients an 3-4 ISDN Basisanschlüssen der T-Com noch keine größere Installation sind, sonst kann ich die QuadBRI auf dem Schreibtisch gleich wieder einstampfen ...

Wie sehen das die anderen ? BRIstuff nichts außerhalb des Heimbetriebs ?

MfG o_dapengiun

 

[Maik]

Sag mir bitte, dass 30-40 interne Clients an 3-4 ISDN Basisanschlüssen der T-Com noch keine größere Installation sind, sonst kann ich die QuadBRI auf dem Schreibtisch gleich wieder einstampfen ...

Das ganze war nur meine Meinung. Es wird viele geben, die das anders sehen. Mir gefällt es halt nicht, dass ich für Bristuff riesen-Patches einspielen muss. Dadurch ist man z.B. auch immer auf bestimmte Versionen von * festgenagelt. Bei 1.0 ist das natürlich nicht ganz so schlimm, aber wenn man eine CVS-Version haben will, kann man Bristuff vergessen.

Hier sind z.B. die Sirrix-Karten im Vorteil. Sirrix liefert einen eigenen Treiber, der mit 1.0 und CVS funktioniert. Der Treiber funktioniert also eigentlich mit jeder halbwegs aktuellen *-Version ausser wenn es mal gerade ne gravierende Änderung gab. Aber selbst dann kommt oft sehr schnell ein Update.

Bei Bristuff wären häufigere Updates für die CVS-Versionen z.B. nicht so einfach möglich, weil es sehr aufwändig ist, die Patches an neuere Versionen anzupassen.

 

[TomS]

@o_dapenguin
Ich habe momentan 2 Produktiv-Systeme mit QuadBRI laufen (bristuffed). Beide Installationen haben <10 IP-Telefone und bis 3 BRI-Anschlüsse. Ist also def. nichts großes, aber mehr als man daheim laufen hat.
Ich habe dabei noch keine ernsthaften Probleme mit den bristuffed-Versionen von Asterisk erlebt. Von CVS-Versionen habe ich bisher allerdings auch lieber die Finger gelassen. Die Updates von Asterisk wurden bisher immer recht flott in die bristuffed-Version eingearbeitet.

Dass die beiden Sourcen (Asterisk u. Bristuff) getrennt laufen ist zwar für Benutzer wie mich unpraktisch, aber ich verstehe die Argumente der beiden Firmen. Solange das Resultat stabil bleibt sehe ich noch keinen Grund die Hardware zu wechseln. Falls es mal mit bristuff nicht mehr weitergehen sollte bleibt ja noch chan_misdn von beronet für die QuadBRI-Karten als Alternative (hab ich allerdings bisher noch nicht ausprobiert)