Hallo Alex,
chan_mobile ermöglicht das koppeln eines Handys via Bluetooth. Man kann dann über das Handy Gespräche in Asterisk empfangen und rauswählen. chan_mobile gaukelt dem Handy quasi eine Bluetooth-Freisprecheinrichtung vor (Hands-Free-Profile). So eine Art GSM-Gateway für Arme, was für mich (Zitat von motte
) aber hinreichend gut funktioniert.
chan_mobile ist (war?) Bestandteil der Asterisk-Addons.
Gruss,
H.
Ah, das ist bei Ubuntu im separaten Paket asterisk-mobile vorhanden! THX - es geht weiter mit Basteln!
Betriebsystem: Ubuntu Lucid Lynx 10.04 Linux-Kernel 2.6.32
VoIP-Software: Asterisk-1.6.2.5
ISDN Hardware: 1*HFC-S TE-Modus (DAHDI/LCR)
@horatio: Für mich sind die tools, insbesondere dahdi_test sehr aufschlussreich, da mir dadurch erst möglich war festzustellen, dass bei mir einfach mal kein Timing ankommt. Hängt davon ab was Du noch dafür tun musst. Nur kompilieren oder portieren? Letzteres wäre es sicher nicht wert.
@alle:
Inzwischen habe ich festgestellt, dass dahdi_test tatsächlich Werte ausspuckt wenn es als erstes geladen wird.
dahdi_scan zeigt mir dann aber auch, dass keine zweite Karte geladen wurde.
Könnte mir jemand einen Tipp geben, wie ich die dahdi/system.conf umzukonfigurieren habe, dass dahdi_dummy auf 1 ist, meine hfc-s auf zwei und meine Karte dahdi_dummy als Timer nutzt? Ich glaube da liegt irgendwie noch mein Fehler.Code:[1] active=yes alarms=UNCONFIGURED description=DAHDI_DUMMY/1 (source: HRtimer) 1 name=DAHDI_DUMMY/1 manufacturer= devicetype=DAHDI Dummy Timing location= basechan=1 totchans=0 irq=0
So sieht es momentan aus:
Ich habe jetzt schonmal alle Kombinationen von span ausprobiert, irgendwie muss ich gestehen verstehe ich den Hintergrund wohl nicht ganz und genconf erzeugt mir nur spanlose Dateien.Code:loadzone<------>= de defaultzone<--->= de span=1,1,3,ccs,ami bchan=1,2 dchan=3
Stefan
Hallo Stefan,
dahdi_test tut es bei mir, python-skripte sind dahdi_genconf, dahdi_hardware und noch ein paar andere. Ich denke dass der Porting-Aufwand für python zumindest nicht gering sein dürfte... mal sehen.
Dass dahdi_scan bei Dir überhaupt keine dahdi-karte anzeigt ist eigenartig, bist Du sicher dass der zaphfc-treiber korrekt geladen wurde? dahdi_scan sollte eigentlich unabhängig von den dahdi-config-files sein, es such wohl direkt nach der Hardware... Bei mir spuckt dahdi_scan jedenfalls auch dann Infos über die vorhandene Hardware aus wenn dahdi_cfg die noch nicht konfiguriert hat.
Meine Experimente (siehe auch einige Posts zuvor) hatten ergeben dass die Reihenfolge die dahdi_scan ausgibt von der Reihenfolge der geladenen Kernel-Module abzuhängen scheint. Wenn Du also dahdi_dummy vor zaphfc lädst, ist dahdi_dummy [1] sonst eben andersrum. Die system.conf muss dann insoweit angepasst werden dass die erste Ziffer hinter "span=" auf die Nummer der Karte aus dahdi_scan gestetzt wird. Alles andere kannst Du so lassen, insbesondere die channels (dchan, bchan) da dahdi_dummy keine Channels anzulegen *scheint*.
Das alles ohne Gewähr, da ich die Sachen mehr oder weniger durch Versuch-und-Irrtum rausgefunden habe, vernünftige Doku dazu ist mir noch nicht untergekommen. Durchaus möglich dass es sich bei Dir anders verhält. Wie schon zuvor erwähnt sitze ich auf etwas spezieller Hardware...
Gruss,
H.
Hallo horatio,
Du hast recht (Ich werde alt), zaphfc war nicht geladen.
War wohl gestern doch etwas viel, und ich hab schon die ganzen Quellen debuggt.
Also erstmal gute Nachricht, mit neuen gepatchten ebuilds dahdi 2.2.1 und dahdi tools 2.2.1 bekomme ich es hin wenn ich ein paar mal wie wild die module lade und entlade eine Antwort von dahdi_test zu bekommen. dahdi_dummy ist bei dahdi_scan dabei nun auf der ersten Stelle und die karte auf der zweiten.
Asterisk meckert nun auch nicht mehr über eine Fehlkonfiguration.
Ich werde nun testen ob es nun auch das Telefonieren geht und berichten.
Danach versuche ich es stabil zu machen.
Nochmal zusammengefasst, alles mit ebuilds unter Gentoo, neuester Kernel + 64 Bit! Das ist das erste mal, dass das Timing bei mir geht, aber noch nicht zu früh gefreut...
Stefan
Ich brauche doch noch einmal Eure Hilfe.
dahdi_scan zeigt mir nun:
Das sieht schonmal gut aus. Auch dahdi_test geht, dahdi_scan, dahdi_speed.Code:[1] active=yes alarms=UNCONFIGURED description=DAHDI_DUMMY/1 (source: HRtimer) 1 name=DAHDI_DUMMY/1 manufacturer= devicetype=DAHDI Dummy Timing location= basechan=1 totchans=0 irq=0 type=digital- syncsrc=0 lbo=0 db (CSU)/0-133 feet (DSX-1) coding_opts= framing_opts= coding= framing= [2] active=yes alarms=UNCONFIGURED description=HFC-S PCI A ISDN card 1 [TE] name=ZTHFC1 manufacturer= devicetype= location= basechan=1 totchans=3 irq=0 type=digital- syncsrc=0 lbo=0 db (CSU)/0-133 feet (DSX-1) coding_opts=AMI framing_opts=CCS coding= framing=
Nun möchte ich den dahdi Dienst neu starten bekomme aber immer nur:
Ich werde das Gefühl nicht los, das liegt an der system.conf. Die ist unverändert:Code:* Stopping DAHDI... [ ok ] * Starting DAHDI... DAHDI_SPANCONFIG failed on span 1: Invalid argument (22)
Hat jemand da einen Tipp für mich. Im Grunde ist es nun doch wieder die gleiche Frage wie in meinem vorletzten Post.Code:loadzone = de defaultzone = de span=1,1,3,ccs,ami bchan=1,2 dchan=3
Vielen Dank für Eure Hilfe
Hi Stefan,
probier in der system.conf mal:
Wie schon erwähnt, musst die erste Ziffer des span mit der Nummer der Dahdi-Karte aus dem dahdi_scan übereinstimmen. Ist lt. Deinem dahdi_scan-output [2], dahdi_dummy liegt auf [1].Code:... span=2,1,3,ccs,ami ...
H.
Hallo horatio,
ich Danke Dir, das hat funktioniert. Ich bin jetzt sehr sehr nah am Ziel.
Wenn alles läuft werde ich dann mal alles zusammenschreiben.
Ich kann leider immer noch keine Anrufe annehmen oder absetzen.
Die asterisk logs sagen mir:
Ich vermute, dass das jetzt eventuell an meiner chan_dahdi.conf liegen könnte. Könnte eventuell jemand nochmal einen Blick darauf werfen?Code:[Jan 24 13:56:34] WARNING[3232] chan_dahdi.c: Unable to specify channel 1: No such device or address [Jan 24 13:56:34] ERROR[3232] chan_dahdi.c: Unable to open channel 1: No such device or address here = 0, tmp->channel = 1, channel = 1 [Jan 24 13:56:34] ERROR[3232] chan_dahdi.c: Unable to register channel '1-2'
Ich habe schon einiges ausprobiert aber bin nicht sicher ob ich noch etwas hinzufügen muss was den channel der Karte angibt.
StefanCode:[trunkgroups] [channels] language=de switchtype=euroisdn pridialplan=dynamic prilocaldialplan=unknown internationalprefix = 00 nationalprefix = 0 ;localprefix = 030 ;privateprefix =. unknownprefix =. facilityenable = yes usecallerid=yes callwaiting=yes usecallingpres=yes callwaitingcallerid=yes threewaycalling=yes transfer=yes canpark=yes cancallforward=yes callreturn=yes immediate=no echocancel=yes echocancelwhenbridged=yes echotraining=yes callgroup=1 pickupgroup=1 mohinterpret=default mohsuggest=default group=1 signalling=bri_cpe_ptmp ; p2p TE mode => bri_cpe ; p2mp TE mode => bri_cpe_ptmp ; p2p NT mode => bri_net ; p2mp NT mode => bri_net_ptmp context=default channel => 1-2
Hi Stefan,
hm, schwer zu sagen. Finde die chan_dahdi.conf generell etwas kryptisch, deshalb weiss ich nicht ob einige Einträge die in Deiner "fehlen" (im Gegensatz zu meiner, siehe Post #93) vielleicht wichtig sind. Im Zweifel mal copy-pasten...
Ansonsten: was spuckt dahdi_cfg -vvv bei Dir aus? Meldet dass Dir vielleicht schon Fehler beim Konfigurieren der Karte?
H.
Hallo Horatio,
ich habe jetzt Deine Config, aber gleiches Problem.
dahdi_cfg -vvv sagt:
module load chan_dahdi.so sagt mir:Code:DAHDI Tools Version - 2.2.1 DAHDI Version: 2.2.1 Echo Canceller(s): OSLEC Configuration ====================== SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1) Channel map: Channel 01: Clear channel (Default) (Echo Canceler: none) (Slaves: 01) Channel 02: Clear channel (Default) (Echo Canceler: none) (Slaves: 02) Channel 03: D-channel (Default) (Echo Canceler: none) (Slaves: 03) 3 channels to configure. Changing signalling on channel 1 from Unused to Clear channel Setting echocan for channel 1 to none Changing signalling on channel 2 from Unused to Clear channel Setting echocan for channel 2 to none Changing signalling on channel 3 from Unused to HDLC with FCS check Setting echocan for channel 3 to none
Ich habe das Gefühl, der will channel 1-2 von meiner ersten Karte, aber das ist dahdi_dummy und geht nicht. Kann das sein?Code:Unable to load module chan_dahdi.so Command 'module load chan_dahdi.so' failed. [Jan 24 16:08:40] WARNING[3264]: pbx.c:5067 ast_register_application2: Already have an application 'DAHDISendKeypadFacility' == Parsing '/etc/asterisk/chan_dahdi.conf': == Found == Parsing '/etc/asterisk/users.conf': == Found [Jan 24 16:08:40] WARNING[3264]: chan_dahdi.c:2121 dahdi_open: Unable to specify channel 1: No such device or address [Jan 24 16:08:40] ERROR[3264]: chan_dahdi.c:10040 mkintf: Unable to open channel 1: No such device or address here = 0, tmp->channel = 1, channel = 1 [Jan 24 16:08:40] ERROR[3264]: chan_dahdi.c:16002 build_channels: Unable to register channel '1-2'
Hallo Stefan,
diese Diskrepanz war mir auch schon einmal aufgefallen (dahdi_scan sagt das die karte auf span 2 liegt, dahdi_cfg behauptet aber es ist span 1), siehe auch mein Post mit den ganzen configs.
Meiner Erfahrung nach steigt dahdi_cfg aber komplett aus wenn man versehentlich versucht dahdi_dummy zu konfigurieren (vielleicht versuchst Du mal die Gegenprobe und setzt den span in der system.conf wieder auf 1 bevor Du dahdi_cfg aufrufst). Ich gehe also mal davon aus dass nur die Ausgabe in dahdi_cfg falsch ist und in Wirklichkeit span 2 gemeint ist. Ich konnte das bei mir verifizieren indem ich vor und nach dahdi_cfg ein dahdi_scan ausgeführt habe. Wenn man die vergleicht sieht man was dahdi_cfg wie konfiguriert hat.
Ansonsten bleibt nur alles nochmal durchzuturnen und zu kucken ob irgendwo was ungewöhnlich ist...
Steht vielleicht was im syslog (dmesg) wenn Du zaphfc lädst was auf ein Problem hindeuten könnte? Oder wenn Du dahdi_cfg aufrufst? Wie in meinem alten Posting schon mal geschrieben, tauchen da bei mir irgendwelche buffer over-/underruns auf, was schon auf ein Problem in den Treibern schließen lässt... und wenn das sowas wie eine Race-condition oder fehlendes locking ist, dann können die Effekte auf unterschiedlichen Maschinen natürlich recht verschieden sein... nur so'n Schuss ins blaue...
Falls Du Dir die Mühe machen willst kannst Du nochmal posten was Du genau für Schritte machst und wie die jeweiligen Ausgaben aussehen. Also vom Laden der Kernel-Treiber über dahdi_cfg bis zum Laden von chan_dahdi in Asterisk.
H.
Hallo Leute,
bin Neuling hier im Forum und auch nachdem ich tagelang gesucht (und teilweise gefunden) habe, komme ich kein Stück mehr weiter. Hoffe aber, es fehlt nicht viel!
Hier meine Konfiguration:
Asterisk 1.6.2.0, 2 x HFC Cologne Chip, mehrere SIP fones, etc.
HFC Karte #0 am ISDN-Privider (ehem Arcor)
Alles funzt soweit – kann ohne Störung stabil via ISDN von/nach „draussen“ telefonieren. SIP fones und andere Provider (SipGate) gehen auch wie gewünscht.
„Was will Sie denn noch?“ werdet ihr fragen.
Banal: ein ganz einfaches ISDN Fone an der HFC Karte #1 ans Laufen bringen.
NTBA inkl. Stromversorgung ist via Cross-over Strippe an der Karte #1. ISDN Fone am NTBA
Das ISDN Fone tut keinen Mucks. Asterisk zuckt nicht einmal, wenn ich am ISDN Fone irgendetwas (Amtsholung) mache.
Wenn ich die Group #2 per DIAL anwähle, erhalte ich vom Asterisk die Fehlermeldung
app_dial.c:1745 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)
Ich komme nicht weiter und kann mir aber nicht vorstellen, dass ich weitab vom Ziel bin.
Sicher, HFC#0 ist im TE, HFC#1 ist im NT Mode. Kernelmodul „zaphc modes=2“ geladen.
Hier ist, was ich noch nicht verstanden habe: Dem ISDN Fone muss ich eine MSN (oder mehrere) zuweisen. Woher weis der Asterisk, welche MSN's es gibt? Einfach über den DIAL Befehl??
Ich mag nicht aufgeben.
Hier einige Konfigurationsfiles bzw wichtige Info's:
charon:/etc/asterisk # dahdi_hardware
charon:/etc/asterisk # dahdi_cfg -vvCode:pci:0000:00:08.0 zaphfc- 1397:2bd0 HFC-S ISDN BRI card pci:0000:00:09.0 zaphfc- 1397:2bd0 HFC-S ISDN BRI card
charon*CLI> dahdi show statusCode:DAHDI Tools Version - 2.2.1 DAHDI Version: 2.2.1 Echo Canceller(s): OSLEC Configuration ====================== SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1) SPAN 2: CCS/ AMI Build-out: 399-533 feet (DSX-1) Channel map: Channel 01: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 01) Channel 02: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 02) Channel 03: D-channel (Default) (Echo Canceler: none) (Slaves: 03) Channel 04: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 04) Channel 05: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 05) Channel 06: D-channel (Default) (Echo Canceler: none) (Slaves: 06) 6 channels to configure. Setting echocan for channel 1 to oslec Setting echocan for channel 2 to oslec Setting echocan for channel 3 to none Setting echocan for channel 4 to oslec Setting echocan for channel 5 to oslec Setting echocan for channel 6 to none
Wahrscheinlich liegt aber hier irgendetwas im Argen:Code:Description Alarms IRQ bpviol CRC4 Fra Codi Options LBO HFC-S PCI A ISDN card 0 [TE] layer 1 AC OK 0 0 0 CCS AMI YEL 399-533 feet (DSX-1) HFC-S PCI A ISDN card 1 [NT] layer 1 AC OK 0 0 0 CCS AMI YEL 399-533 feet (DSX-1)
charon:/etc/asterisk # cat chan_dahdi.conf
Code:[trunkgroups] [channels] language=de switchtype=euroisdn pridialplan=dynamic ;prilocaldialplan=unknown internationalprefix = 00 nationalprefix = 0 localprefix = 0511 privateprefix = 0511123456 unknownprefix = facilityenable = yes signalling = bri_cpe ; p2p TE mode => bri_cpe ; p2mp TE mode => bri_cpe_ptmp ; p2p NT mode => bri_net ; p2mp NT mode => bri_net_ptmp ; usecallerid=yes callwaiting=yes usecallingpres=yes callwaitingcallerid=yes threewaycalling=yes transfer=yes canpark=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=yes echotraining=yes ;echotraining=800 ;rxgain=2.0 ;txgain=3.0 ; group=1 callgroup=1 pickupgroup=1 mohinterpret=default mohsuggest=default context=default signalling = bri_cpe immediate=yes channel => 1-2 callerid = asreceived group = 2 context=default signalling = bri_net_ptmp channel => 4-5
charon:/etc/asterisk # cat ../dahdi/system.conf
Code:span=1,1,3,ccs,ami bchan=1-2 dchan=3 span=2,1,3,ccs,ami bchan=4-5 dchan=6 echocanceller=oslec,1-2,4-5 loadzone = de defaultzone = de
In der extensions.conf steht u. a. ein
exten => 2002,1,Dial(DAHDI/g2/INT_MSN,30)
wobei INT_MSN die dem ISDN Fone zugewiesene MSN ist.
Über ein beliebiges, anderes SIP Fone wähle ich die 2002 an. Dann kommt die "Congestion" Fehlermeldung. Setze ich in o. g. DIAL Kommando den Channel auf "g1" und die Nummer auf meine (externe) MSN, wählt der brave Asterisk brav über meinen Provider 'raus - wie es sich gehört....
Sorry für dieses lange posting, aber ich weis mir sonst keinen Rat mehr – aber ich denke auch, dass meine Frage zum Thread-Thema passt.
Vielen Dank!!
Wilhelmine
Geändert von wilhelmine (23.01.2010 um 19:35 Uhr)
@Wilhelmine:
Womit hast Du dahdi denn gepatcht um zaphfc zum Laufen zu bekommen und auf welcher Distribution läuft das alles. Und aus eigenem Interesse, was ist es für eine Maschine? (32 /64 Bit?)
Soweit ich weiss funktionieren die zaphfc patches die ich nutze garnicht im NT Modus, genau mit den Problemen, von denen Du sprichst.
Ich bekomme leider nur nicht einmal hin überhaupt rein/oder rauszuwählen.
Kleiner Tipp noch, ich finde es übersichtlicher wenn man Auszüge aus Configs in code blöcke stellt.
@ horatio, ich bin dabei alles noch einmal zu überprüfen, jedoch sieht alles bei mir sehr sauber aus bis auf das bekannte problem bei chan_dahdi.
dmesg sagt auch nichts auffälliges:
Wenn ich in system.conf span=1,1,3,ccs,ami statt span=2,1,3,ccs,ami dann bekomme ich den Fehler in der letzten Zeilde der Ausgabe, alles andere bleibt gleich:Code:dahdi: Telephony Interface Registered on major 196 dahdi: Version: 2.2.1 dahdi_transcode: Loaded. dahdi_echocan_oslec: Registered echo canceler 'OSLEC' dahdi_dummy: Trying to load High Resolution Timer dahdi_dummy: Initialized High Resolution Timer dahdi_dummy: Starting High Resolution Timer dahdi_dummy: High Resolution Timer started, good to go zaphfc: jitterbuffer size: 1 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 18 pci 0000:01:07.0: PCI INT A -> Link[LNKD] -> GSI 18 (level, low) -> IRQ 18 zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0x110d4800 fifo 0x2e9b0000(0x2e9b0000) IRQ 18 HZ 1000 zaphfc: Card 0 configured for TE mode zaphfc: Card 0 configured for master mode zaphfc: 1 hfc-pci card(s) in this box.
Code:DAHDI Tools Version - 2.2.1 DAHDI Version: 2.2.1 Echo Canceller(s): OSLEC Configuration ====================== SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1) Channel map: Channel 01: Clear channel (Default) (Echo Canceler: none) (Slaves: 01) Channel 02: Clear channel (Default) (Echo Canceler: none) (Slaves: 02) Channel 03: D-channel (Default) (Echo Canceler: none) (Slaves: 03) 3 channels to configure. DAHDI_SPANCONFIG failed on span 1: Invalid argument (22)
Hallo sflemming,
hier die gewünschten Info's:
"Normaler" 32 bit intel (irgendein altes Billig-komplett-Teil fuer 200,- EUR) mit 2GB RAM
Neueste SuSE 11.2 32 bit drauf, inkl Kernel src und Compilerumgebung. Nun wurd's ja interessant.
- Neueste Asterisk 1.6.2 vom *.org
- Die DAHDI Linux
- DAHDI Tools (Achtung: den Komplett tarball habe ich ums Verrecken nicht sauber compiliert bekommen - beide einzeln liefen wie geölt)
- LibPRI
Den Patch "dahdi-linux-2.2.0.2_zaphfc.tar" aus diesem Thread hier auf den "linux" Teil appliziert -> Ohne Mucken
Asterisk configured mit --with-dahdi=path_to_patched_dahdi_linux
make, make install. usw.
Ja und das wars eigentlich. Bevor der Asterisk gestartet wird, muessen ja die kernelmodule dahdi, zaphfc modes=2 und ggfs ein echocanceller geladen werden. Modprobe war mein Freund.
Mehr war eigentlich nicht notwendig (sagt sich so schön, hat schon ein paar tage gedauert, weil ich in etliche Sachgassen gelaufen bin
Ist hier jemand der bestätigen kann, dass das wie oben beschrieben gepatchte zaphfc den NT mode nicht unterstützt??
Dann kann ich das Basteln nämlich beenden....was schade wäre...
Danke fürs Lesen.
Ciao
Wilhelmine
Hallo alle,
unter http://www.gsurf.de/typo3temp/pics/582a67d8ea.jpg habe ich exakt das gefunden, was ich mit den 2 HFC Karten hier vorhabe. Dort http://www.gsurf.de/index.php?id=30 wird jedoch die Verwendung von mISDN vorausgesetzt.
Meine Frage: Hat dies jemand mit der hier beschriebenen Kombination bestehend aus dem Patch und den 2 HFC Karten geschafft? Falls "ja", dann wäre ich sehr an ein paar Tips interessiert, denn ich weis nicht mehr weiter...
Herzlichen Dank!
Wilhelmine
Ja, ICH kann es Dir bestätigen...geht mit den hier beschriebenen Patches für zaphfc definitiv nicht.
...kann ich nachvollziehen. Aber wenn Du Zeit und Lust hast, kannst Du gerne mal versuchen, die flammneuen Patches von http://code.google.com/p/zaphfc/ in Betrieb zu nehmen. Vielleicht können die schon den NT-Modus; jedenfalls sind sie gerademal ein paar Wochen alt. Die alten Patches haben nun ja bald schon 1 Jahr auf dem Buckel...Dann kann ich das Basteln nämlich beenden....
Ich selber habe sie mangels Zeit und freier Hardware noch nicht richtig zum laufen bekommen - heißt, sie kompilieren und laden prima, aber das wars dann auch schon.
-
Larry
Geändert von Larry (02.02.2010 um 12:01 Uhr) Grund: Typo
Betriebsystem: Gentoo Linux, Kernel 3.1.10-gentoo-r1
VoIP-Server: Asus M2A-VM/AMD Phenom 9850 Quad
VoIP-Software: Asterisk-1.8.8.x Branch, vzaphfc/dahdi-Patches, chan-sccp-b, Asterisk-Desktop-Manager, SpanDSP, Skype For Asterisk
VoIP-Phones: 1*Cisco 7921/SCCP, 2*Cisco 7960/SCCP, 2*Cisco 7970/SCCP, 1*Cisco 7936/SCCP, 1*Snom 190, 1*Grandstream GXV3000, 1*Grandstream BT101, 1*Grandstream GXP2000, 1*AllNet 7950, 1* Targa DIP450
Asterisk Hardware: 1*HFC-S TE-Modus (DAHDI), 1*BeroNet BN4S0 TE+NT-Modus (DAHDI)
Stefan und meiner einer konzentrieren uns derweil in zahlreichen Mails darauf, die alten Patches (ich nenne sie fürderhin nur noch "alte Patches" oder eben zaphfc - die gaaaanz neuen nennen sich dann vzaphfc) erst einmal *grundsätzlich* zum laufen zu bewegen.
Wobei ich sagen muss, dass sie bei mir auf allen Gentoo/x86-PCs *nie* Schwierigkeiten machen und tadellos laufen. Auspacken, patchen, kompilieren, läuft.
Anders sieht es bei Gentoo/x86_64 aus: Auf meinem "Desktop"-System rennen sie mittlerweile prima und stressfrei, hingegen auf ein und derselben Hardware/Kernel, nur mit einem kleinen und schlanken Gentoo, tun sie nur bei "Schönwetter"...ganz seltsam das.
Den anderen interessierten und fleißigen hier kann ich nur ans Herz legen, erst zaphfc und hiernach alles andere zu laden. Der erste Kartentreiber (auch dahdi_dummy zählt zu den Kartentreibern) legt wohl einen dahdi-Timer an, alle weiteren nicht (oder "huckepack" - man möge mich korrigieren).
dahdi_test prüft dann einen gültigen Timer und wenn dahdi_dummy der erste Kartentreiber ist, erhält man immer prima Werte, egal ob weitere/funktionierende Treiber/Timer vorhanden sind oder nicht.
Außerdem legt sich dahdi_dummy, wenn als erstes geladen, breit und faul auf Span1, was bei weiteren (dahdi-)Konfigurationen berücksichtigt werden muss, obwohl dahdi_dummy ja eigentlich nur für app_meetme benötigt wird (auch hier möge man mich ggf. korrigieren).
Für mich zum schnellen testen hat sich daher folgendes bewährt:
- dahdi/zaphfc bauen
- zaphfc als erstes (oder einziges) laden
- /etc/init.d/dahdi neu starten (ganz wichtig!)
- dahdi_test laufen lassen.
Kommen dann bei dahdi_test keine Werte, kann ich mir alle weiteren Mühen schenken. Werden allerdings Werte ausgegeben, Heureka, kann ich sicher sein, dass auch Asterisk dann tut.
-
Larry
Betriebsystem: Gentoo Linux, Kernel 3.1.10-gentoo-r1
VoIP-Server: Asus M2A-VM/AMD Phenom 9850 Quad
VoIP-Software: Asterisk-1.8.8.x Branch, vzaphfc/dahdi-Patches, chan-sccp-b, Asterisk-Desktop-Manager, SpanDSP, Skype For Asterisk
VoIP-Phones: 1*Cisco 7921/SCCP, 2*Cisco 7960/SCCP, 2*Cisco 7970/SCCP, 1*Cisco 7936/SCCP, 1*Snom 190, 1*Grandstream GXV3000, 1*Grandstream BT101, 1*Grandstream GXP2000, 1*AllNet 7950, 1* Targa DIP450
Asterisk Hardware: 1*HFC-S TE-Modus (DAHDI), 1*BeroNet BN4S0 TE+NT-Modus (DAHDI)
Hey Larry,
Das verstehe ich noch nicht. Die vzaphfc-Module gibt es doch schon ewig. Was ist daran neu? Gleichzeitig kann ich Deine Patches nicht auf die Ubuntu-dahdi-source-Package anwenden (siehe mein Posting #82). Die compilieren aber auch ohne Patches gut - sehen dann allerdings nur so aus als könnten sie funktionierendie alten Patches (ich nenne sie fürderhin nur noch "alte Patches" oder eben zaphfc - die gaaaanz neuen nennen sich dann vzaphfc) erst einmal *grundsätzlich* zum laufen zu bewegen.
Wodurch wird eigentlich nochmal der Oslec-Echocanceller gebaut? Ist der in den Patches enthalten?
Ich probiere das nochmal nach Deiner letzten Anleitung, sobald ich Zeit finde. Aber ich rechne auch mit einigem Aufwand: Vielleicht muss ich aber auch dahdi-Originalquellen benutzen und das dann vielleicht mit neuen Patches, wenn die alten nicht mehr auf den neuen Quellen funktionieren. Eine andere Idee hätte ich sonst nicht, warum nach dem Patchen das Compilieren nicht mehr funktioniert...
VG, Alex.
Betriebsystem: Ubuntu Lucid Lynx 10.04 Linux-Kernel 2.6.32
VoIP-Software: Asterisk-1.6.2.5
ISDN Hardware: 1*HFC-S TE-Modus (DAHDI/LCR)
Jein, Du meinst wahrscheinlich das vzaphfc für bristuff. Ich meinte dieses hier.die alten Patches (ich nenne sie fürderhin nur noch "alte Patches" oder eben zaphfc - die gaaaanz neuen nennen sich dann vzaphfc) erst einmal *grundsätzlich* zum laufen zu bewegen.
Da kann ich Dir nichts zu sagen; ich beziehe mich bei den von mir vorgestellten Patches immer nur auf die Original-Sources.Gleichzeitig kann ich Deine Patches nicht auf die Ubuntu-dahdi-source-Package anwenden (siehe mein Posting #82)
Ist in "meinen" Patches immer enthalten, bzw. mit eingebunden. Letztlich ein billiger Trick: Man nehme die Dateien aus /usr/src/linux/drivers/staging/echo und lege sie in /pfad/zu/dahdi-linux-2.2.0.2/drivers/staging/echo/ ab. Danach noch in /pfad/zu/dahdi-linux-2.2.0.2/drivers/dahdi/Kbuild die folgenden Zeilen entkommentieren/ergänzen:Wodurch wird eigentlich nochmal der Oslec-Echocanceller gebaut? Ist der in den Patches enthalten?
...und fertig.Code:obj-m += dahdi_echocan_oslec.o obj-m += ../staging/echo/echo.o
Frag doch mal Frau Google. Ich meine mich erinnern zu können, dass es für Ubuntu bereits fertige dahdi-Pakete mit dem neuen vzaphfc gibt...[...] Vielleicht muss ich aber auch dahdi-Originalquellen benutzen und das dann vielleicht mit neuen Patches, wenn die alten nicht mehr auf den neuen Quellen funktionieren. Eine andere Idee hätte ich sonst nicht, warum nach dem Patchen das Compilieren nicht mehr funktioniert...
-
Larry
Betriebsystem: Gentoo Linux, Kernel 3.1.10-gentoo-r1
VoIP-Server: Asus M2A-VM/AMD Phenom 9850 Quad
VoIP-Software: Asterisk-1.8.8.x Branch, vzaphfc/dahdi-Patches, chan-sccp-b, Asterisk-Desktop-Manager, SpanDSP, Skype For Asterisk
VoIP-Phones: 1*Cisco 7921/SCCP, 2*Cisco 7960/SCCP, 2*Cisco 7970/SCCP, 1*Cisco 7936/SCCP, 1*Snom 190, 1*Grandstream GXV3000, 1*Grandstream BT101, 1*Grandstream GXP2000, 1*AllNet 7950, 1* Targa DIP450
Asterisk Hardware: 1*HFC-S TE-Modus (DAHDI), 1*BeroNet BN4S0 TE+NT-Modus (DAHDI)
Hallo zusammen,
danke (besonders an Larry) für die detallierteren Beschreibungen Eurer Setups. Habe mal versucht mein Setup ohne dahdi_dummy zum Laufen zu bringen, da scheitert dann tatsächlich der dahdi_test wieder... ich habe nicht so ganz gerafft was dahdi_test eigentlich testet? Geht es da nicht um timing accuracy? Versucht der die ISDN-Zeit der Vermittlungsstelle auszulesen?
Komme also nicht wirklich weiter. Mein Verdacht ist - da ich als einziger diese buffer under-/overflows zu haben scheine - dass der gegenwärtige Patch nicht mit *zwei* HFC-"Karten" (in meinem Fall Chips) zurecht kommt, kann das sein? Irgendein Problem mit inkorrektem locking im zaphfc-Treiber?
Da der NT-Modus ja mit diesen Treibern nicht funktioniert, gehe ich mal nicht davon aus dass das jemand von Euch es schon mal mit zwei Karten probiert hat, oder?
Wie gesagt es handelt sich in meinem Fall *nicht* um einen dual-port chip, sondern tatsächlich um zwei separate hfc-s chips... warumauchimmer das so gelöst wurde... und deaktivieren liesse sich der zweite chip leider nur mit dem Lötkolben, fürchte ich... also nix was ich ausprobieren möchte...
Vielleicht versuche ich mich mal an den vzaphfc-treibern, danke für den Hinweis.
Danke & Gruss,
H.
Berechtigungen
Zitieren
