Verbindung Asterisk und interner S0 d. TK Anlage streikt

milamber

Neuer User
Mitglied seit
20 Jun 2005
Beiträge
47
Punkte für Reaktionen
0
Punkte
0
Hi Leute,

ich habe ein Problem mit der Verbindung von Asterisk über eine HFC Karte zum internen S0 Bus einer Auerswald ETS 4308i TK-Anlage.

Zur Verbindung benutze ich ein selbstgelötetes Kabel mit Widerständen nach Christophers Blog. Alles scheint normal zu funktionieren. Wenn man dann die Verbindung zwischen HFC und internem S0 Bus herstellt, hört man an einem anderen Telefon, dass auch am internen S0 Bus hängt nur noch Rauschen und andere Störgeräusche.
Kann das Problem dadurch verursacht werden, dass zwischen HFC und internem S0 Bus noch eine ISDN Dose hängt?
Muss die HFC Karte im NT Modus laufen oder nicht? Wo kann man das überprüfen bzw. in den TE Modus wechseln?
Wenn sonst noch jemand ne Idee hat, her damit.


Dann habe ich beim Starten von Asterisk noch folgende Fehlermeldung gesehen. Würde aber mal sagen, dass das nicht wirklich was mit dem HFC Problem zu tun hat. Wäre nett, wenn mir dazu jemand nen Tipp geben kann.

Code:
 [chan_skinny.so] => (Skinny Client Control Protocol (Skinny))
Aug 25 00:14:21 WARNING[3449]: chan_skinny.c:2587 reload_config: Unable to get our IP address, Skinny disabled

Schonmal vielen Dank im Voraus.

Grüsse
Benjamin
 
Hallo Benjamin,
die Warnung kriegst Du mit dem Eintrag in der modules.conf

noload => chan_skinny.so

weg. Hat aber nichts mit Deinem eigentlichen Problem zu tun.
 
Um einen Asterisk an den internen So der TK-Anlage anzuschliessen brauchst du nur ein ganz normales ISDN-Kabel (kein gekreuztes). Die Karte muss in den TE-Modus. Den NT-Modus und das spezielle gekreuzte Kabel braucht man nur, wenn man Telefone direkt an den Asterisk anschliessen will.
 
@ ploieel

Danke für den Tipp. Fehler ist weg. :)



@ Maik

Vielen Dank. Das funktioniert jetzt schonmal so weit. Und ich hab mal wieder löten geübt. HFC ist jetzt im TE Modus.

Jetzt würde ich den * gerne so konfigurieren, dass man von einer Nebenstelle der Telefonanlage 45 (ISDN Nebenstellen sind die Nummern 41-48 ) wählt und dann der * abnimmt. Dann wählt man ne 1 für SIPGate und ne 2 für Freenet usw.
Danach kommt die eigentliche Nummer, die angerufen werden soll. Wie macht man das am Besten?
Kann übrigens auch gut sein, dass ich noch irgendwelche Klopper in der Konfig habe :)
Vielen Dank.

Gruss
Benjamin

extensions.conf
Code:
[default]
;include => vmailbox
;include => external-ISDN
include => external-SIP
include => <<SIPID>>

[external-SIP]
;exten => _0.,1,Dial(SIP/${EXTEN:1}@<<SIPID>>,30,Ttr)
;exten => _0.,2,Congestion
;bei mir wird mir der "Vorwahl" 1 über den Account rausgewählt.
exten => _1.,1,NoOp(Call via Sipgate DE)
exten => _1.,2,SetCallerID(<<SIPID>>)
exten => _1.,3,Dial(SIP/${EXTEN:1}@<<SIPID>>,60,r)
exten => _1.,4,Congestion
exten => _1.,5,Busy
exten => _1.,6,Hangup


[<<SIPID>>]
exten => <<SIPID>>,1,Dial(Zap/g1/301,60)
;301 ist Gruppenrufnummer der TK Anlage
exten => <<SIPID>>,2,Hangup


zapata.conf
Code:
[channels]
language=de
switchtype=euroisdn
signalling=bri_net_ptmp
pridialplan=local
echocancel=yes
immediate=no
;setcallerid(""<${CALLERIDNUM}>)
usecallerid = yes
overlapdial=no ;geändert
group=1
context=default
channel=>1-2
usecallingpres=yes
nationalprefix = 0
internationalprefix = 00
; 
;signalling = bri_cpe_ptmp = Mehrgeräteanschluss
;bri_net_ptp = Anlagenanschluß
;group = 2 
;channel => 4-5


sip.conf
Code:
[general]
port = 5060
bindaddr = 0.0.0.0
;          xyz.dyndns.org mit DNS Namen des Fli4l PC's ersetzen
externhost = xxx.dyndns.org
;          192.168.0.0/255.255.0.0 mit eigener Netzadresse und Netzmaske ersetzen (IP_NET_1 aus base.txt)
Localnet = 192.168.0.200/255.255.255.0
srvlookup = yes
context = external-SIP
disallow=all
allow=gsm
canreinvite=no
tos=0x18
insecure=very
nat=no
dtmfmode=info

register => <<SIPID>>:<<SIPPASSWORT>>@sipgate.de/<<SIPID>>

[<<SIPID>>]
type=friend
username=<<SIPID>>
fromuser=<<SIPID>>
secret=<<SIPPASSWORT>>
context=external-SIP
host=sipgate.de
fromdomain=sipgate.de
insecure=very
;caninvite=no
canreinvite=no
nat=no
disallow=all
allow=ulaw

[sipgate_de_in]
type=peer
fromdomain=sipgate.de
host=sipgate.de
context=ankommend
 
[default]
include => external-SIP
include => <<SIPID>>

Kann ich bitte deine IP haben? :)
Mach das besser weg sonst kann jeder, der dich per z.B. SIP anruft, auf deine Kosten raustelefonieren. In der sip.conf solltest du uebrigens auch unter [general] den context auf default setzen.

Dann solltest du noch einen weiteren Kontext einfuehren fuer ankommende ISDN-Gespraeche und den auch in der zapata.conf eintragen. Da kommt dann nur eine exten rein (45) mit der application 'DISA'.
 
Den Dyndns Eintrag hab ich glatt übersehen :oops:

Habe in der sip.conf den context unter general auf default geändert.
Danach habe ich den zusätzlichen context in zapata und extensions eingefügt. Leider nimmt der * noch nicht ab, obwohl sich kurz nach dem Wählen ein leiser Knackser in der Leitung hören lässt. Vielleicht auch Wunschdenken :)

Hier nochmal die beiden geänderten Dateien. Was ist eigentlich der Unterschied zwischen _45.; 45.;_45;45 ? Habe jetzt mal 45 und davor _45. ausprobiert. Ergebnis ist das gleiche.
Nochmal vielen Dank für deine Hilfe.

Gruss
Benjamin

extensions.conf
Code:
[default]
;include => vmailbox
;include => external-ISDN
include => external-SIP
include => <<SIPID>>

[external-SIP]
;exten => _0.,1,Dial(SIP/${EXTEN:1}@<<SIPID>>,30,Ttr)
;exten => _0.,2,Congestion
;bei mir wird mir der "Vorwahl" 1 über den Account rausgewählt.
exten => _1.,1,NoOp(Call via Sipgate DE)
exten => _1.,2,SetCallerID(<<SIPID>>)
exten => _1.,3,Dial(SIP/${EXTEN:1}@<<SIPID>>,60,r)
exten => _1.,4,Congestion
exten => _1.,5,Busy
exten => _1.,6,Hangup


[<<SIPID>>]
exten => <<SIPID>>,1,Dial(Zap/g1/301,60)
;301 ist Gruppenrufnummer der TK Anlage 
exten => <<SIPID>>,2,Hangup


[ISDN-IN]
exten => 45,1,DISA,no-password|default


zapata.conf
Code:
[channels]
language=de
switchtype=euroisdn
signalling=bri_net_ptmp
pridialplan=local
echocancel=yes
immediate=no
;setcallerid(""<${CALLERIDNUM}>)
usecallerid = yes
overlapdial=no ;geändert
group=1
context=ISDN-IN
channel=>1-2
usecallingpres=yes
nationalprefix = 0
internationalprefix = 00
 
Hi Leute,

ich bin langsam am Verzweifeln. 4 Tage und keine wesentliche Verbesserung. Das einzige was meine Rumprobiererei geändert hat ist, dass vorher beim Anrufen der Asterisk MSN nur das Freizeichen kam. Jetzt kommt nach 1-2xFreizeichen ein Besetztzeichen. Hab mich noch nicht entschieden, ob ich das besser finden soll oder nicht.

Ich habe absolut keine Idee woran es noch liegen könnte. Zur Sicherheit habe ich mal ein ISDN Telefon auf die MSN 45 programmiert und es an das Kabel gehängt das für den * bestimmt ist. Es hat einwandfrei funktioniert.

In anderen Postings lese ich immer so viel von Logausgaben. Bei mir loggt der * nichts. Es steht nur manchmal was mit chan_sip drin, wenn er sich nicht beim ersten mal bei sipgate anmelden konnte.
Das einzige was mir logmäßig von der HFC Karte untergekommen ist, sind ca. 320 Zeilen direkt nach nem Reboot mit b channel bufferunderun/overflow. Zwischendurch steht sehr selten auch mal tx sync changed.

Hat noch jemand ne Idee? Vielen Dank.

Gruss
Benjamin

extensions.conf
Code:
[default]
include => external-SIP
include => <<SIPID>>
exten => _45.,1,DISA,no-password|default

[external-SIP]
;bei mir wird mit der "Vorwahl" 1 über den Account rausgewählt.
exten => _1.,1,NoOp(Call via Sipgate DE)
exten => _1.,2,SetCallerID(<<SIPID>>)
exten => _1.,3,Dial(SIP/${EXTEN:1}@<<SIPID>>,60,r)
exten => _1.,4,Congestion
exten => _1.,5,Busy
exten => _1.,6,Hangup

[<<SIPID>>]
exten => <<SIPID>>,1,Dial(Zap/g1/301,120)
;301 ist Gruppenrufnummer der TK Anlage 
exten => <<SIPID>>,2,Hangup


zapata.conf
Code:
[channels]
;language=de
switchtype=euroisdn
signalling=bri_net_ptmp
pridialplan=local
prilocaldialplan=local 
echocancel=yes
echocancelwhenbridged=no
echotraining=no 
usecallerid = yes
overlapdial=no ;geändert
immediate=no
;setcallerid(""<${CALLERIDNUM}>)
group=1
context=default
channel=>1-2


sip.conf
Code:
[general]
port=5060
bindaddr=0.0.0.0
;          xyz.dyndns.org mit DNS Namen des Fli4l PC's ersetzen
externhost=<<DYNDNS Adresse>>
;          192.168.0.0/255.255.0.0 mit eigener Netzadresse und Netzmaske ersetzen (IP_NET_1 aus base.txt)
Localnet=192.168.0.200/255.255.255.0
srvlookup=yes
context=default
disallow=all
allow=gsm
canreinvite=no
tos=0x18
insecure=very
nat=no
dtmfmode=info

register => <<SIPID>>:<<SIPPW>>@sipgate.de/<<SIPID>>

[<<SIPID>>]
type=friend
username=<<SIPID>>
fromuser=<<SIPID>>
secret=<<SIPPW>>
context=external-SIP
host=sipgate.de
fromdomain=sipgate.de
insecure=very
;caninvite=no
canreinvite=no
nat=no
disallow=all
allow=ulaw
allow=alaw

[sipgate_de_in]
type=peer
fromdomain=sipgate.de
host=sipgate.de
context=ankommend
 
Starte doch mal asterisk mit asterisk -vvvvvgc, mache einen Anrufversuch und dann poste die Ausgaben hier.
 
@ ploieel

Danke für deine Antwort.

Das merkwürdige an meinem Problem ist, dass keinerlei Logausgaben kommen die irgendwas mit der HFC Karte zu tun haben könnten.

logger.conf Auszug
Code:
debug => debug
;console => notice,warning,error
;console => notice,warning,error,debug
console => notice,warning,error,debug,verbose
messages => notice,warning,error
full => notice,warning,error,debug,verbose

Auszug aus der Full log Datei
Code:
[pbx_config.so] => (Text Extension Configuration)
Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/extensions.conf': Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/extensions.conf': Found
Aug 30 17:34:57 VERBOSE[4122]:     -- Registered extension context 'default'
Aug 30 17:34:57 VERBOSE[4122]:     -- Including context 'external-SIP' in context 'default'
Aug 30 17:34:57 VERBOSE[4122]:     -- Including context '<<SIPID>>' in context 'default'
Aug 30 17:34:57 VERBOSE[4122]:     -- Added extension '_45.' priority 1 to default
Aug 30 17:34:57 VERBOSE[4122]:     -- Registered extension context 'external-SIP'
Aug 30 17:34:57 VERBOSE[4122]:     -- Added extension '_1.' priority 1 to external-SIP
Aug 30 17:34:57 VERBOSE[4122]:     -- Added extension '_1.' priority 2 to external-SIP
Aug 30 17:34:57 VERBOSE[4122]:     -- Added extension '_1.' priority 3 to external-SIP
Aug 30 17:34:57 VERBOSE[4122]:     -- Added extension '_1.' priority 4 to external-SIP
Aug 30 17:34:57 VERBOSE[4122]:     -- Added extension '_1.' priority 5 to external-SIP
Aug 30 17:34:57 VERBOSE[4122]:     -- Added extension '_1.' priority 6 to external-SIP
Aug 30 17:34:57 VERBOSE[4122]:     -- Registered extension context '<<SIPID>>'
Aug 30 17:34:57 VERBOSE[4122]:     -- Added extension '<<SIPID>>' priority 1 to <<SIPID>>
Aug 30 17:34:57 VERBOSE[4122]:     -- Added extension '<<SIPID>>' priority 2 to <<SIPID>>
Aug 30 17:34:57 VERBOSE[4122]:  [pbx_spool.so]Aug 30 17:34:57 VERBOSE[4122]:  [pbx_spool.so] => (Outgoing Spool Support)
Aug 30 17:34:57 VERBOSE[4122]:  [pbx_wilcalu.so]Aug 30 17:34:57 VERBOSE[4122]:  [pbx_wilcalu.so] => (Wil Cal U (Auto Dialer))
Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/enum.conf': Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/enum.conf': Found
Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/extconfig.conf': Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/extconfig.conf': Found
Aug 30 17:34:57 VERBOSE[4122]: Asterisk Event Logger restarted
Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/manager.conf': Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/manager.conf': Found
Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/enum.conf': Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/enum.conf': Found
Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/rtp.conf': Aug 30 17:34:57 VERBOSE[4122]:   == Parsing '/etc/asterisk/rtp.conf': Found
Aug 30 17:34:57 VERBOSE[4122]:   == RTP Allocating from port range 10000 -> 20000
Aug 30 17:34:57 VERBOSE[4122]: Asterisk Ready.
Aug 30 17:36:42 DEBUG[4135]: Scheduled a registration timeout # 5
Aug 30 17:36:42 DEBUG[4135]: Stopping retransmission on '[email protected]' of Request 104: Found
Aug 30 17:36:42 DEBUG[4135]: Registration successful
Aug 30 17:36:42 DEBUG[4135]: Cancelling timeout 5

In dieser Zeit habe ich mehrere Male versucht anzurufen aber es passiert einfach nichts. Das einzige das kommt, passiert zeitlich unabhängig vom Anrufen.

Gruss
Benjamin
 
Hallo;
ich sehe schon, so einfach wird das nichts.
Hast Du Deinen Fli-Router in der Nähe? Wenn ja, kannst Du folgendermaßen vorgehen, um einmal zu sehen, was (oder was nicht) beim Asterisk funktioniert:

- auf dem Fli einloggen, das Menü mit Strg+c abbrechen
- am fli-prompt asterisk -r eingeben
- am cli-prompt stop gracefully eingeben
- am fli-prompt asterisk mit asterisk -vvvvvgc neu starten
- einen Anruf versuchen und die Ausgaben des cli ansehen und gegebenenfalls auswerten

Besser wäre es natürlich, wenn Du Dir auf dem Windows-Rechner den ssh-Client putty installierst, dort die Prozedur wie oben beschrieben auf dem fli-Rechner ausführst; dann kannst Du die Ausgaben des cli per c&p hier posten; dann sehen wir mal weiter.
 
ploieel schrieb:
Besser wäre es natürlich, wenn Du Dir auf dem Windows-Rechner den ssh-Client putty installierst, dort die Prozedur wie oben beschrieben auf dem fli-Rechner ausführst; dann kannst Du die Ausgaben des cli per c&p hier posten; dann sehen wir mal weiter.

Im Prinzip hab ich genau das gemacht. Nur habe ich die Ausgabe nicht von der Console bzw. dem Putty Fenster, sondern von der konfigurierten Log Datei kopiert.
Auf der Console steht aber auch nichts anderes. Es gibt definitiv keine Log Ausgaben zur HFC Karte (die weiter oben erwähnten nach dem Bootvorgang ausgenommen).
Ich hab keine Ahnung woran das liegt. Ist vielleicht die Karte kaputt? Ich hatte sie ja am Anfang mal falscherweise mit gekreuztem Kabel angeschlossen.
Danke für deine Hilfe.

Gruss
Benjamin

Edit:
Das bekomme ich gerade auf der Console. Aber wieder nichts mit HFC
Code:
Asterisk Ready.
*CLI> Aug 30 20:47:52 DEBUG[4191]: chan_sip.c:4175 transmit_register: Scheduled a registration timeout # 5
Aug 30 20:47:53 DEBUG[4191]: chan_sip.c:840 __sip_ack: Stopping retransmission on '[email protected]' of Request 104: Found
Aug 30 20:47:53 DEBUG[4191]: chan_sip.c:6776 handle_response: Registration successful
Aug 30 20:47:53 DEBUG[4191]: chan_sip.c:6778 handle_response: Cancelling timeout 5
Aug 30 20:49:38 DEBUG[4191]: chan_sip.c:4175 transmit_register: Scheduled a registration timeout # 8
Aug 30 20:49:38 DEBUG[4191]: chan_sip.c:840 __sip_ack: Stopping retransmission on '[email protected]' of Request 105: Found
Aug 30 20:49:38 DEBUG[4191]: chan_sip.c:6776 handle_response: Registration successful
Aug 30 20:49:38 DEBUG[4191]: chan_sip.c:6778 handle_response: Cancelling timeout 8
 
Wenn das mit dem buffer underrun / overflow kommt, sind meist Interruptprobleme der Grund dafür. Das hatte ich bis vor wenigen Tagen auch. Trotzdem hatte mein Asterisk funktioniert. Wobei ich nicht den 1.4beta draufhabe, sondern noch den "ohne beta", ich glaube 1.3.

Die buffer-Meldungen sind bei mir weg, seitdem ich das opt_hdtune auf den Router draufgespielt habe. Offenbar verhindert das opt Interrupt-Probleme. Ist vielleicht einen Versuch wert, dieses opt mal auszuprobieren. Ich glaube nicht, dass Deine Karte defekt ist. Wenn Du den Fli neu startest und Du einen Monitor dranhast, solltest Du Meldungen durchrauschen sehen, wo die hfc-Karte die channels bildet, 2 b-Kanäle und einen d-Kanal.
 
Das mit opt_hdtune wird leider nichts. Der Router läuft nur mit SCSI Platten und einem Adaptec 78xx onboard SCSI Controller. SCSI Platten werden leider nicht unterstützt.
Gibts noch irgendwas das ich ausprobieren kann.

Danke und Gruss
Benjamin
 
Schreib bitte mal: beim Neustart des Routers laufen Meldungen durch, und kurz hält die Anzeige mal an bei Zaptel und drei Kanäle eingerichtet oder so. Kannst Du eigentlich nicht verpassen... ob Du das sehen kannst.
 
Sieht man das nur beim Neustart des Routers? Ich bin im Moment nämlich nicht am Standort des Routers. Erst wieder am Freitag.

Hilft dir vielleicht das weiter?

Code:
fli4l:/ # ztcfg -vvvvv

Zaptel Configuration
======================

SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1)

Channel map:

Channel 01: Individual Clear channel (Default) (Slaves: 01)
Channel 02: Individual Clear channel (Default) (Slaves: 02)
Channel 03: D-channel (Default) (Slaves: 03)

3 channels configured.
 
Ich habe jetzt mal beim Rebooten auf die Ausgaben geachtet. Allerdings ist mir dabei nichts von zaptel oder so aufgefallen.
"Hängenbleiben" tut er nur beim Laden des SCSI Treibers und beim Laden des ext3 Treibers.

Gruss
Benjamin
 
Die Log-Ausgaben von weiter oben sagen eigentlich, dass die drei Kanäle stehen...

Dein Asterisk müsste eigentlich laufen.... jedenfalls an der Hardware, sprich HFC-Karte, kann es nicht liegen.

Der Jürgen schreibt auf seiner Homepage, dass er die 1.4beta für einen PentiumI kompiliert hat. Wenn Dein Router aber auf einem PentiumII läuft, warum hast Du dann den 1.4beta-Asterisk drauf? Klar; wie man sieht, scheint die Hardware richtig zu laufen.... aber vielleicht kommt ein Teil Deiner Probleme von der 1.4beta? Andererseits funktioniert aber ein ISDN-Telefon solo an Deinem Asterisk problemlos, wie Du weiter oben geschrieben hast... grübel grübel.... wenn der cli keine log-Ausgaben macht, kanns eigentlich nur daran liegen, dass beim Asterisk nichts von den Eingaben mittels Telefon ankommt, denn ansonsten würde der cli ja reagieren und irgendwas anzeigen. Und solange da nichts angezeigt wird, kann ich von hier aus leider nur herumrätseln. Ich könnte mir nur noch vorstellen, dass mit dem Kabel von der HFC-Karte zur Telefon-Anlage etwas nicht hinhaut.

Kannst ja nochmal den Schritt zurückgehen: das ISDN-Telefon solo an den Asterisk anschließen und schauen, ob der cli etwas loggt. Wenn ja, kannst Du davon ausgehen, das der Asterisk hardwaremäßig richtig läuft. Den gleichen Zustand (wo log-Ausgaben vom cli zu sehen sind) solltest Du dann beim Anschluss der Telefon-Anlage an den Asterisk herstellen. Die Fehler und Unzulänglichkeiten, die in den log-Ausgaben benannt sind, erstmal außen vorlassen. Nur ganz ohne die log-Ausgaben stocherst Du im Nebel... :-(

Immer langsam und Schritt für Schritt vorgehen; "wilde" Herumprobiererei bringt hier nichts. So nach dem bewährten Grundsatz:

Immer ruhich und gediechn - was nich fertich wird, bleibt liechn. ;-)
 
Hmm. Jetzt muss ich erstmal ein Missverständnis ausräumen:
Ich hatte kein ISDN Telefon an der HFC angeschlossen, sondern ein ISDN Telefon an die TK Anlage mit exakt der Verkabelung die ich normalerweise für die HFC benutze.

Das mit Version 1.4 beta ist ganz einfach zu erklären. Es ist neuer :) . Wenn ich das richtig verstanden habe, werde sowieso alle folgenden Versionen nur noch für P1 kompiliert sein.

Ich hab in einem anderem Thread jemanden mit einem ähnlichen Problem gefunden. Seine Lösung war, dass er in der modules.conf die chan_zap.so nicht geladen hatte.
Ich hab daraufhin mal bei mir nachgeschaut und der Eintrag fehlte natürlich. Nach dem Hinzufügen des Eintrags startet der * mit unten angegebener Fehlermeldung nicht mehr.
Brauch man den Eintrag bei HFC Karten im TE Modus oder kann ich das wieder raus werfen?
Wie bekomme ich die Fehlermeldung weg, wenn man den Eintrag braucht?
Vielen Dank.

Gruss
Benjamin


modules.conf
Code:
[modules]
autoload=yes
noload => pbx_gtkconsole.so
noload => pbx_kdeconsole.so
noload => chan_modem_i4l.so
noload => chan_modem_bestdata.so
noload => chan_modem_aopen.so
noload => chan_modem.so
noload => app_intercom.so
noload => chan_capi.so
load => res_musiconhold.so
load => chan_zap.so
noload => chan_elsa.so
noload => chan_oss.so
noload => chan_skinny.so
[global]
chan_capi.so=no

Fehlermeldung beim Laden von Asterisk
Code:
Asterisk Dynamic Loader Starting:
Sep  4 17:53:52 DEBUG[4134]: config.c:787 __ast_load: Parsing /etc/asterisk/modules.conf
 [res_musiconhold.so] => (Music On Hold Resource)
Sep  4 17:53:52 DEBUG[4134]: config.c:787 __ast_load: Parsing /etc/asterisk/musiconhold.conf
  == Registered application 'MusicOnHold'
  == Registered application 'WaitMusicOnHold'
  == Registered application 'SetMusicOnHold'
 [chan_zap.so]Sep  4 17:53:52 DEBUG[4134]: config.c:787 __ast_load: Parsing /etc/asterisk/modules.conf
Sep  4 17:53:52 WARNING[4134]: loader.c:258 ast_load_resource: /usr/lib/asterisk/modules/chan_zap.so: undefined symbol: ast_retrieve_call_to_death
Sep  4 17:53:52 WARNING[4134]: loader.c:391 load_modules: Loading module chan_zap.so failed!
 
Es sieht so aus, als wäre die chan_zap.so nicht verfügbar. Kann es vielleicht sein, dass die 1.4 beta für zap gar nicht geht? Hier bin ich echt am Ende. Nimm deshalb doch bitte mal Kontakt mit Jürgen Röllgen auf, er ist m. E. der Einzigste, der Dir hier weiterhelfen kann.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,831
Beiträge
2,219,105
Mitglieder
371,533
Neuestes Mitglied
ipeee
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.