Zap oder mISDN

CLauinger

Neuer User
Mitglied seit
27 Jan 2005
Beiträge
94
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

ich habe hier meinen "*" mit chan_misdn laufen. Ich habe nun gelesen das meine HFC Karte auch mit zaphfc laufen könnte.
Was ist die bessere Alternative für Debian Sarge ?
Auf meinem Testrechner hab ich mal mit zaphfc im TE Mode rum experimentiert, mit dem Erfolg das sich die "*" nach dem der Anruf beendet wurde abstürzt.
Habe dieses Howto verwendet:

Debian zaphfc HowTO

Was mich gestört hat:
Mit den passenden Kernel-Headern installiert, klappt das
module-assistant update;module-assistant auto-install zaptel
dann auch. Nach geglücktem Compilieren kann danach das generierte zaptel-modules Paket (mittels dpkg -i /usr/src/zaptel-modules*.deb;depmod -a;modprobe zaphfc) installiert werden. (Hilfe gibt's aktuell immer unter /usr/share/doc/zaptel-source/README.Debian)
Mittels modprobe zaphfc kann das Kernelmodul dann geladen werden. Sofern NT-Mode benötigt wird, muss mit modprobe zaphfc modes=1 gearbeitet werden und sehr wahrscheinlich muss die ztcfg-Ausführung von /etc/modprobe.d/zaptel und /etc/modutils/zaptel auskommentiert und update-modules laufen gelassen werden. Momentan gilt, dass ztcfg nur GENAU EINMAL nach dem Laden des zaphfc-Moduls ausgeführt werden darf. Alle weiteren Versuche, das Modul zu initialisieren, werden zwar nicht mit einem Fehler quittiert, aber dafür stellt die Karte jeglichen Dienst ein. Wenn also sämtliche Anrufe von und zu ISDN nicht klappen, dann als erstes die automagischen ztcfg Aufrufe ausbauen und nach dem Laden des Modules einmal händisch ausführen (rmmod zaphfc;modprobe zaphfc modes=1;ztcfg -vv). Wenn dann asterisk startet (asterisk -U asterisk -vvvvvvv), ist zumindest das Problem identifiziert (Lösungsvorschläge bitte an mich oder den Upstream).
Ist das wirklich notwendig: "die automagischen ztcfg Aufrufe ausbauen" ?
Was verwendet ihr so ? mISDN oder zaphfc ?

Grüße

Christian
 
Momentan gilt, dass ztcfg nur GENAU EINMAL nach dem Laden des zaphfc-Moduls ausgeführt werden darf. Alle weiteren Versuche, das Modul zu initialisieren, werden zwar nicht mit einem Fehler quittiert, aber dafür stellt die Karte jeglichen Dienst ein.

Also dieses Verhalten (siehe quote) scheint in den aktuellen Versionen von zaphfc gefixed worden zu sein.

Die Entscheidung ob Zap oder mISDN hängt auch vom Kernel ab. Mit mISDN benötigst du einen Kernel 2.6 (AFAIK am besten 2.6.8 ).
Der mISDN Support muss in den Kernel kompiliert werden, was sich evtl. auch als K.O.-Kriterium herausstellen kann.

bristuff/zaphfc funktioniert auch mit dem Kernel 2.4. Und es reicht, dass Modul zu kompilieren.
Dazu sind dann "nur" vorhandene kernel-header und kernel-sourcen nötig (Achtung: Der laufende Kernel muss mit den sourcen/headern zusammenpassen, also ggf das aktuellste kernel-image installieren).

Das Debian asterisk- und zaptel-Package ist zwar jeweils "bristuffed", bringt aber das zaphfc Modul nicht mit, d.h. das Modul musst du auf jeden Fall selbst erstellen.

Mir war es aber nicht möglich, das asterisk Debian-Package zusammen mit dem selbst kompilierten zaphfc Modul zu verwenden (kann aber leicht an einem Fehler meinerseits gelegen haben).

Meine Vorgehensweise zum erstellen des zaphfc (bzw jetzt qozap) Moduls war ein bischen anders, daher musste ich auch keine "automagischen" Aufrufe deaktivieren.

Zu Features/Stabilität/Performance-Unterschieden zwischen bristuff-zaptel und mISDN kann ich leider nix sagen.


--
my 0.02¤
 
also chan misdn läuft seit neuestem hier recht gut, diese zaphfc geschichte teste ich schon 2 tage. die ergebnisse sind miserabel.

ich bekomme zaphfc weder mit apt-get source zaptel / module-assistant, noch mit dieser bristuff geschicht von junghanns sauber zum laufen.
"*" bekommt nicht mit das aufgelegt wurde und irgendwann stürzt es ab :(
kann mir mal bitte einer schreiben, ders auf debian am laufen hat, wie ers gemacht hat ?

gruss
 
Hi,

ich kann nur sagen, dass ich mit mISDN einen Haufen Probleme hatte. Ich habe ne * mit 3xHFC-S, einmal TE-PTP ans Amt und 2x intern NT-PTMP. Mit mISDN wurden die Gespräche nicht sauber beendet, danach mußte der * teilweise neu gestartet werden, weil der S0 tot war. Das könnte auch mit dem sicher nicht ganz standardmäßigem S0 Bus zusammenhängen. Aber an der alten abgelösten elmeg ging das ohne Probleme und mit den bristuff läuft es auch seit über 2 Wochen ohne Probleme und Abstürze. Selbst Datentransfer vom PC aus, der mit einer Fritz-PCI an der * hängt.
Das einzige was ich noch nicht hinbekommen habe, sind die attended Transfers. Siehe hier: http://www.ip-phone-forum.de/forum/viewtopic.php?t=17840 und die Besetztanzeige http://www.ip-phone-forum.de/forum/viewtopic.php?t=17846

Ich habe Debian Sarge mit Kernel 2.6.8. und bristuff-0.2.0-RC8d drauf.

Grüße

stargaizer
 
Also dafür habe ich schon zahlreiche erfolglose Stunden damit verbracht zu versuchen mISDN zu installieren, Zaphfc hingegen gingen relativ problemlos :)

Was genau möchtest Du zur Installation von Zaphfc wissen? Ich habe die Kernel-Sourcen installiert und anschliessend die Installations-Routine von Junghanns gestartet.

Im Betrieb läuft Zaphfc bei mir äusserst stabil (keine Abstürze erlebt bislang) Dafür bin ich mit der Sprachqualität nicht zufrieden, aber da weiss ich nicht, ob Zaphfc dafür verantwortlich ist.
 
Dakapo schrieb:
Was genau möchtest Du zur Installation von Zaphfc wissen? Ich habe die Kernel-Sourcen installiert und anschliessend die Installations-Routine von Junghanns gestartet.
Das habe ich auch schon probiert, auf meiner Teststellung. Der Erfolg war das die Gespräche nicht sauber beendet werden und "*" deswegen abstürzt.

Die Junghanns bristuff-Geschichte installiert ja nicht nur den zaphfc Treiber sondern auch Asterisk wenn ich das richtig gesehen habe.

Was ich wissen will ist, ob das Howto aus meinem 1. Post was taugt, oder ob ihr alle die Junghanns Geschichte anstatt apt-get verwendet.

Grüße
 
Also bei Debian Sarge ist zwar * 1.0.7 mit bristuff dabei, hatte mich auch schon gefreut, aber die Kenelmodule nicht :-(
Also downloade einfach das bristuff Archiv, entpacke es und lass den install Script laufen. Der macht alles incl. Download von *. Das geht völlig unbroblematisch, sofern du Compiler etc. auf dem System hast. Dann nur noch die Configs anpassen und fertig. Beispiele gibt's im bristuff Archiv selbst und auch hier im Forum genug.
Ich glaube, die Versuche zu dem Debian * die Kernelmodule separat zu bauen kosten dich nur Zeit. Wobei ich natürlich auch lieber ein fertiges deb genommen hätte.

stargaizer
 
Ich stimmte stargaizer da vollkommen zu. Es ist wirklich keine grosse Schwierigkeit alles über die Junghanns-Skripte zu installieren. Mit den fertigen Paketen von Debian habe ich keine Erfahrung. Aber für eventuelle Fehler bei Junghanns wirst Du sehr schnell Hilfe bekommen, da es stark verbreitet ist und es viele Erfahrungen damit gibt.

Schmeiss mal die Debian-Pakete wieder raus, hol Dir die Kernel-Sourcen und entpacke sie nach /usr/src

Wenn Du einen 2.6er Kernel verwendest musst Du für Asterisk noch einen Link /usr/src/linux-2.6 auf die Kernel-Sourcen anlegen.
 
stargaizer schrieb:
Also bei Debian Sarge ist zwar * 1.0.7 mit bristuff dabei, hatte mich auch schon gefreut, aber die Kenelmodule nicht :-(
Also downloade einfach das bristuff Archiv, entpacke es und lass den install Script laufen. Der macht alles incl. Download von *. Das geht völlig unbroblematisch, sofern du Compiler etc. auf dem System hast. Dann nur noch die Configs anpassen und fertig. Beispiele gibt's im bristuff Archiv selbst und auch hier im Forum genug.
Ich glaube, die Versuche zu dem Debian * die Kernelmodule separat zu bauen kosten dich nur Zeit. Wobei ich natürlich auch lieber ein fertiges deb genommen hätte.

stargaizer
Hmm das fertige deb finde ich besser als diese Junghanns Geschichte, allein schon wegen dem Update das immer wieder runtergeladen werden muss.
Mit apt ist es viel wartungsfreundlicher.
Hat jemand ne Anleitung um nur die zaphfc-Kernelmodule aus dem Junghanns -Paket zu bauen ? Das fände ich die beste Lösung.

Grüße
 
ich finde das misdn und chan_misdn besser. vor allem auf leistungsschwacher hardware ist das bristuff zeugs absolut unbrauchbar und auch sonst hochgradig instabil. das misdn zeugs laeuft jetzt bei mir jetzt bis auf eine kleinigkeit gut nach einigen anlaufschwierigkeiten. chan_misdn hat fuer mich den vorteil das es zum beispiel ein online bug tracking system gibt und dort entwickler von beronet diese auch "abarbeiten".

cu tommi
 
tarzanwiejane schrieb:
ich finde das misdn und chan_misdn besser. vor allem auf leistungsschwacher hardware ist das bristuff zeugs absolut unbrauchbar und auch sonst hochgradig instabil. das misdn zeugs laeuft jetzt bei mir jetzt bis auf eine kleinigkeit gut nach einigen anlaufschwierigkeiten. chan_misdn hat fuer mich den vorteil das es zum beispiel ein online bug tracking system gibt und dort entwickler von beronet diese auch "abarbeiten".

cu tommi
Das kann ich nicht ganz so bestätigen. Bei mir auf einem Duron 1300, ok nicht der ganz langsamste, verursachen 3xHFC einen zu vernachlässigenden load von unter 0,10, wenn alle sprechen. Und vorher auf einem 400er Celeron wars glaube ich auch nicht mehr.
Ich hatte, wie schon geschrieben, mit den mISDN richtige Stabilitätsprobleme. Kommt aber sicher auf eine Menge Faktoren an. Sodaß hier immer wieder sehr unterschiedliche Aussagen kommen dürften. Ist halt alles noch ein wenig experimentell.
Aber da wir als OpenSource'ler ja frei wählen können, kann sich ja jeder das für ihn beste raussuchen :)

stargaizer
 
Hmm hierzu meine Erfahrungen mit BRIStuff und mISDN:

BRIStuff:
+lässt sich ziemlich problemlos installieren
-es wird fremder Code gepatcht (ZAP ist ja eigentlich für die analogwelt gedacht, sehe ich als keine sehr saubere Lösung an)
-Ab einer gewissen Revision (weis nimmer genau welche, sind zuviele), prüft der Treiber für die 4- und 8-Port Karte ob es sich um eine Junghanns Karte handelt, ist dem nicht der Fall funktioniert nicht alles.
-man ist fest an die entsprechende Asterisk Version gebunden

mISDN
-komplizierter zu installieren
-läuft nur noch mit 2.6er Kernel
-hat noch ein paar Macken mit generierung eines internen Anlagen S0
+ist die eigentlich native Unterstützung
+ist Asterisk "unabhängig", sprich freie Versionswahl
+unterstützt alle Quad und Octo Karten unabhängig vom Hersteller
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.