GSM-Codecs

[robinsonR]

Ich hatte die Frage schon im Trixbox-Forum gestellt, aber leider keine Antwort (Lösung) erhalten. Vielleicht ist es ja allgemeinerer Natur.
Kann es sein, dass mein Asterisk (1.2.19) die GSM-Codecs nicht verträgt (stürzt beim Starten mit Coredump ab), weil der Rechner (350 MHz, 384 MB RAM) zu schwach ist?
Oder wo muss ich noch nach Fehlern suchen?

 

[jam4ever]

wäre eigentlich eher seltsam... ist es ein asterisk-system oder "nur" die trixbox?

 

[robinsonR]

Es ist eine aktuelle Version von Trixbox 2.2 (Neuinstallation)

 

[jam4ever]

auf die gefahr hin, mich zu wiederholen...
schonmal probiert, einen "reinen" asterisk aufzusetzen?
ohne das trixbox-konstrukt drumherum?

 

[robinsonR]

Edit Rocky512 - Vollzitat von Beitrag darüber entfernt. Bitte die Forumregeln beachten!
___

Natürlich könnte ich einen reinen Asterisk aufbauen und die ganzen Konfigurationen und Optionen von Trixbox nachbauen. Nur, was soll das bringen?
Ich habe eine zweite Trixbox-Installation ohne dieses Problem. Und wenn ich schon von vorne anfangen soll, kann ich auch ebensogut die Trixbox nochmals neu installieren. Darum ja die Frage, ob es evtl. an der Hardware liegen kann. Wenn es daran liegt, würde auch eine reine Asterisk-Installation nichts bringen, da mit der Trixbox ja nur die Konfiguration einfacher wird. Die Engine ist ja nach wie vor Asterisk; momentan ja in der aktuellen Version 1.2.19.

Habe es jetzt lösen können. Hat mich zwar ¤ 55 gekostet, dafür aber habe ich kompetente Hilfe gekriegt. Ich habe mein Problem hier geschildert und innerhalb kürzester Zeit wurde mein Problem behoben. Es war, wie ich vermutet hatte, die CPU meines Asterisk-Servers. Es wurde einfach Asterisk 1.2.19 neu kompiliert und siehe da, es funktioniert.

 

[jam4ever]

gut, dass dir geholfen werden konnte.
bei einer selbstinstallation wäre dir das nicht passiert - du hättest den asterisk da eh kompilieren müssen SCNR
hauptsache es läuft jetzt bei dir

 

[robinsonR]

Edit Rocky512 - Vollzitat von Beitrag darüber entfernt. Bitte die Forumregeln beachten!
___

Ja, wenn man dann erkennt, mit welchen Optionen kompiliert werden soll. Denn auch wenn man Trixbox installiert, wird Asterisk kompiliert. Leider eben mit Standard-Optionen und die waren eben falsch gesetzt. Die Firma, die mir geholfen hat, hat dann einen Bug-Report an die Asterisk-Entwickler geschickt, damit das in einer nächsten Version nicht mehr vorkommen sollte.

 

[jam4ever]

okay... jetzt bin ich neugierig...
mit welchen optionen wurde denn bei dir kompiliert?
bzw welche "standard-optionen" haben das ganze crashen lassen?

 

[robinsonR]

Edit Rocky512 - Vollzitat von Beitrag darüber entfernt. Bitte die Forumregeln beachten!
___

Kann ich leider nicht sagen. Wie schon erwähnt, gab ich nur an, was der Dienstleister mir mitgeteilt hatte.

Anscheinend lag das Problem an meinem Asterisk-Server

model name : AMD-K6(tm) 3D processor
stepping : 12
cpu MHz : 350.844

it could be reason for gsm codec problem.
Now I have download Asterisk 1.2.19 source for detailed analyze.

Ich frage mich einfach noch, warum dich das so interessiert, da du mich ja nicht für voll nehmen kannst, da ich Trixbox einsetze und nicht die ganze Installation von Grund auf selber aus den Sourcen kompiliere und das Rad zum x-ten Mal neu erfinde. ;-)

 

[betateilchen]

Interessanterweise treten bei mir mit einer AMD CPU auch Probleme beim Kompilieren von Asterisk 1.2.20 auf - der Abbruch erfolgt genau beim Kompilieren der GSM Teile :verdaech:

 

[robinsonR]

Gemäss der Firma, die das für mich gemacht hatte, ist dieser Bug schon gemeldet worden. Wohl aber zu spät, um in die aktuelle Version (1.2.20) einzufliessen. Wird wohl noch gemacht oder dann auf 1.4 verwiesen.

 

[Netview]

Dann schaut mal ins Makefile (die GSM-Optimierung sollte bei AMD-Prozessoren auf Kommentar stehen):

######### More GSM codec optimization
######### Uncomment to enable MMXTM optimizations for x86 architecture CPU's
######### which support MMX instructions.  This should be newer pentiums,
######### ppro's, etc, as well as the AMD K6 and K7.  
#K6OPT  = -DK6OPT <==

 

[robinsonR]

Sollte das dann nicht automatisch geschehen, wenn der Compiler merkt, welche CPU am Werk ist?

 

[Netview]

Sollte das dann nicht automatisch geschehen, wenn der Compiler merkt, welche CPU am Werk ist?

Nein - leider nicht!

 

[jam4ever]

Ich frage mich einfach noch, warum dich das so interessiert, da du mich ja nicht für voll nehmen kannst, da ich Trixbox einsetze und nicht die ganze Installation von Grund auf selber aus den Sourcen kompiliere und das Rad zum x-ten Mal neu erfinde. ;-)

ich nehme jeden für voll, nur hat ja auch jeder andere vorlieben und erfahrungen. ich habe zum beispiel schon mehrfach nicht so tolle erfahrungen
mit der trixbox gemacht, und meide das system daher im moment. wenn mir wieder mehr gutes zugetragen wird, kann man seine meinung natürlich wieder ändern.
ausserdem ist meiner meinung nach kompilieren nicht das rad neu erfinden.
den compiler für eine architektur neu zu schreiben ist schon eher vergleichbar damit. aber auch das passiert, wenn das alte eisenbeschlagene kutschenrad
gegen einen modernen reifen gewechselt wird.

 

[betateilchen]

ich habe zum beispiel schon mehrfach nicht so tolle erfahrungen mit der trixbox gemacht, und meide das system daher im moment.

Ich mag Trixbox auch nicht so besonders und habe schon des öfteren empfohlen auf einen "richtigen" Asterisk zu setzen. Trotzdem ist es zu respektieren, wenn andere User damit arbeiten. Noch dazu, wo das hier aufgetretene Problem überhaupt nicht Trixbox-spezifisch zu sein scheint, denn ich verwende nur "richtige" Asteriske

Darüberhinaus gehe ich auch davon aus, daß in 1.2.21 dieser Bug behoben sein wird. Allerdings habe ich den gescheiterten Kompilier-Versuch erstmal ohne weitere Fehlersuche dazu genutzt, den betreffenden Asterisk am Wochenende gleich komplett auf 1.4 umzustellen :mrgreen:

 

[robinsonR]

Nein, natürlich ist «Kompilieren» nicht das Rad neu erfinden. Wie ich schon geschrieben hatte, kompiliert Trixbox ja bei der Installation Asterisk ja auch aus den Quellen.
Mit «Rad neu erfinden» meinte ich, dass man Dial-Pläne, IVR, usw. nicht von Grund auf neu aufbauen muss, sondern mit relativ wenig Aufwand ein mehr oder weniger gelücktes GUI hat, bei dem nur noch Parameter angegeben werden müssen.
Auch MySQL und wenn man es braucht HUDLite sowie Sugar-CRM werden installiert und entsprechend konfiguriert.

 

[robinsonR]

Nein - leider nicht!

Ich meinte, gerade das sei der Bug, der gemäss Aussage dieser Firma, gemeldet wird.