Capio auf der FritzBox

[bodega]

Was hast du für eine Box? Bei der 7170 sieht es so aus:
Ctrl. 1 : ISDN (extern)
Ctrl. 3 : ISDN (intern, S0)
Ctrl. 4 : Analog
Ctrl. 5 : VoIP

"Keine CAPI vorhanden" ist etwas wenig. Gab es auch einen Fehlercode?
Ansonsten überprüfe auch mal bitte, ob die "EXPORTS" der Environment Variablen stimmen.

Vielleicht auch mal mit 'ldd' schauen (Asterisk Binary/Module), ob der Link auch auf die libcapi20... zeigt. Nicht das eine andere CAPI statisch einkompiliert wurde. Dann sei vielleicht noch zu fragen, wie die Ausgabe von capiinfo aussieht und ob noch eine zusätzliche ISDN-Karte im Rechner steckt.

 

[ozett]

habe ne 7050.

gehe den tip mit den exports mal nach, da ich diese immer für den jeweiligen user nachsetzen muss. da stimmen sie dann aber. capiinfo funktioniert ja auch.
asterisk wird allerdings über amportal als user asterisk gestartet. vielleicht müssen irgendwie in das environment die exports?

root@pbx:/usr/lib $ ls -l libcap*
lrwxrwxrwx 1 root root 25 Jul 30 16:18 libcapi20_remote.so -> libcapi20_remote.so.3.0.4
lrwxrwxrwx 1 root root 25 Jul 30 16:18 libcapi20_remote.so.3 -> libcapi20_remote.so.3.0.4
-rwxr-xr-x 1 root root 29318 May 4 20:42 libcapi20_remote.so.3.0.4
lrwxrwxrwx 1 root root 18 Jul 30 16:18 libcapi20.so -> libcapi20.so.3.0.4
lrwxrwxrwx 1 root root 18 Jul 30 16:18 libcapi20.so.3 -> libcapi20.so.3.0.4
-rwxr-xr-x 1 root root 38703 May 4 20:42 libcapi20.so.3.0.4

lld ist noch nicht drauf, prüfe den hinweis aber. ergebnis sieht ok aus, oder?
root@pbx:/usr/sbin $ ldd asterisk
linux-gate.so.1 => (0x0047f000)
libdl.so.2 => /lib/libdl.so.2 (0x00171000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00137000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x00110000)
libm.so.6 => /lib/libm.so.6 (0x00f18000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00da1000)
libc.so.6 => /lib/libc.so.6 (0x0048f000)
/lib/ld-linux.so.2 (0x00227000)
bei der prüfung mit ldd von chan_capi und chan_misdn und /usr/lib/libmISDN.so habe ich allerdings gar keine verweise auf capi gefunden. ist das der fehler?

bei capiinfo wird wohl die richtige benutzt:
ldd /usr/bin/capiinfo
linux-gate.so.1 => (0x00db8000)
libcapi20.so.3 => /usr/lib/libcapi20.so.3 (0x00401000)
libc.so.6 => /lib/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x008a3000)


ansonsten keine weitere karte vorhanden. installation läuft in einer vm. (pbxinaflash, centos5, Asterisk 1.4.21.2,
Linux pbx.local 2.6.18-53.1.14.el5 #1 SMP Wed Mar 5 11:36:49 EST 2008 i686 i686 i386 GNU/Linux)

in (etc/capi.conf und /etc/capi20.conf angelegt. hilft nicht. irgenwas mit udev notwendig?

danke,
ozett

ps.: es sieht so aus, als sei misdn nicht notwendig weil libcapi gar nicht auf misdn zugreift und vorher bereits auf die capi-zugriffe auf die remote-fritzbox umleitet, oder? nach diesem diagramm der schichten: http://www.misdn.org/index.php/About_mISDN.
heisst aber, dass chan_capi auf libcapi zugreifen müsste und damit müsste es gehen, oder?

 

[bodega]

Die Libs sehen ok aus. capiinfo ist auch korrekt. Die exports müsstest du eigentlich nur ändern, wenn die FB von der Standard-IP abweicht (192.168.178.1). Ansonsten kannst du das vernachlässigen.

Soweit mir bekannt ist, bindet chan_capi.c das -lcapi20 Modul ein.
-llinuxcapi20 wird eingebunden, wenn "#define C4B 1" gesetzt ist. Im aktuellen Source der "chan_capi-1.1.1" entdecke ich ebenfalls ein "libcapi20" Unterverzeichnis. Ich bin mir nicht sicher, ob die chan_capi eventuell mit dieser Version gebaut wurde (und dann vielleicht sogar static, da 'ldd' nichts ausgibt).
Es könnte sein, dass du chan_capi neu übersetzen musst mit neuer libcapi20. Also auch das Unterverzeichnis libcapi20 austauschen!

Wie gesagt... ich kann leider nur Hinweise geben. Aber wir kommen schon vorran - es muss halt nur am Ende noch klappen

 

[ozett]

aufmunterung tut gut, also (wie richtig geraten) zuletzt auch das chan_capi 1.1.1 neu heruntergeladne, ausgepackt, die dateien im unterverzeichnis libcapi20 ersetzt durch die quellen aus der (remote-)libcapi-2.0_fb-0.3.tar.gz aus diesem thread, kompiliert und installiert, asterisk gestartet mit:

== Parsing '/etc/asterisk/capi.conf': Found
asterisk: symbol lookup error: /usr/lib/asterisk/modules/chan_capi.so: undefined symbol: capi20_fb_tcp_isinstalled

und nu?

aber grossen dank bis hierher, echt,
ozett

 

[bodega]

Mhh.. anscheinend wurde da eine Datei zu wenig einkompiliert....
Im Makefile von chan_capi folgendes ändern:

1. Möglichkeit:

ifeq (${USE_OWN_LIBCAPI},yes)
OBJECTS += libcapi20/convert.o libcapi20/capi20.o [COLOR="Red"]libcapi20/capi20_fb_tcp.o[/COLOR] libcapi20/capifunc.o
endif

damit sollte lcapi20 statisch eingebunden sein (also die aus dem libcapi20 Verzeichnis).

ODER

2. Möglichkeit:

USE_OWN_LIBCAPI=[COLOR="Red"]no[/COLOR]

damit "sollte" lcapi20 dynamisch eingebunden werden (aus /usr/lib....). Dies ist aber defaultmäßig aus - warum auch immer. Deswegen würde ich es vorerst mit Punkt 1 probieren.

Ansonsten schaue ich heute abend nochmal nach... mach das momentan im Blindflug.

 

[ozett]

super blindflug,
im makefile der chan_capi 1.1.1

USE_OWN_LIBCAPI=no

gesetzt und in asterisk geladen. volltreffer geht.
beim laden eine fehlermeldung:

[Jul 31 15:33:16] ERROR[15500] chan_capi.c: Unable to listen on contr1 (error=0x100f)
[Jul 31 15:33:16] NOTICE[15500] chan_capi.c: Unused contr2
[Jul 31 15:33:16] NOTICE[15500] chan_capi.c: Unused contr3
[Jul 31 15:33:16] NOTICE[15500] chan_capi.c: Unused contr4
[Jul 31 15:33:16] VERBOSE[15500] logger.c: == Registered channel type 'CAPI' (Common ISDN API Driver (1.1.1))
[Jul 31 15:33:16] VERBOSE[15500] logger.c: == Registered application 'capicommand'
[Jul 31 15:33:16] VERBOSE[15500] logger.c: Loaded chan_capi.so => (Common ISDN API Driver (1.1.1))
[Jul 31 15:33:16] NOTICE[15502] chan_capi.c: Started CAPI device thread.

sieht aber gut aus, auf asterisk-cli die capi info:
capi info
Common ISDN API Driver (1.1.1) www.chan-capi.org
Contr1: 2 B channels total, 2 B channels free.
Contr2: 2 B channels total, 2 B channels free. (unused)
Contr3: 2 B channels total, 2 B channels free. (unused)
Contr4: 1 B channels total, 1 B channels free. (unused)

jetzt muss ich nochmal nachschauen ob contrl1 passt, wenn
Ctrl. 1 : ISDN (extern)
Ctrl. 3 : ISDN (intern, S0)
Ctrl. 4 : Analog
Ctrl. 5 : VoIP
das stimmt und mal telefonieren testen. Hoffentlich ist die fehlermeldung nur kosmetisch.

erstnochmal danke und für die hilfen bis hier:
:rosen::rock:

 

[bodega]

Das sieht doch mal gut aus, bis auf den Listen-Fehler. Es könnte daran liegen, dass die Confirmation zu lange brauch oder das usleep-Intervall im Code zu hoch gestellt ist. Bin gespannt auf deine Rückmeldung, ob es dennoch klappt...

Jedoch hätte ich Möglichkeit 1 vorgezogen. Irgendwas müssen sich die Entwickler dabei gedacht haben, wenn sie libcapi20 fest einkompilieren.

EDIT:
Die Sache findet in der Datei chan_capi_utils.c statt - Funktion "capi_ListenOnController()".
Dort gibt es einmal die Variable waitcount=50. Die könnte man erhöhen.
Das usleep(30000) in der while-Schleife kann man reduzieren oder erhöhen. Keine Ahnung was da besser wäre. In der libcapi20 ist eh ein select() enthalten, so das man das usleep() auch weglassen könnte.
Vielleicht ist es auch gut, nach dem capi_sendf(...) ein usleep(25) einzubauen. Alles nur Möglichkeiten...
Die ApplId wird anscheinend nur einmal registriert.

 

[ozett]

so, auch mit möglichkeit 1 compiliert und usleep um faktor 9 vergrössert. immer gleiche fehlermeldung beim laden von chan_capi 1.1.1 (und auch mit chan_capi-HEAD),

ERROR[17679] chan_capi.c: Unable to listen on contr1 (error=0x100f)

obwohl sonst wirklich alles gut aussieht werden keine eingehende rufe angezeigt oder ausgehende rufe vermittelt. asterisk wählt endlos raus, kein freizeichen,nix weiter... timeout

[Jul 31 17:32:58] VERBOSE[17723] logger.c:     -- Called contr1/0123456789
[Jul 31 17:34:58] VERBOSE[17723] logger.c:   == ISDN1#02: CAPI Hangingup for PLCI=0 in state 5
[Jul 31 17:35:00] WARNING[17723] chan_capi_utils.c: ISDN1#02: timed out waiting for

im rcapi-thread scheint es irgendwie mit kleineren fehlern zu gehen. mittlerweile zweifel ich aber etwas, ob es grundsätzlich geht...

gibts hoffnung?

grüsse,
ozett

 

[bodega]

Also ich schaue gerade drüber. Ich bekomme auch die gleiche Meldung. Das interessante ist aber, das ich eine merkwürdige ApplID zurückgeliefert bekomme. Ich schaue mal, ob das ein Endianess Problem ist.

Die Hoffnung stirbt zu letzt Vor allem, weil ich momentan Elan dazu habe.

 

[ozett]

wie komme ich an die appID?

etwas elan habe ich auch noch

 

[bodega]

Hey ozett,

ich glaube das geht doch irgendwie:

    -- listening on contr1 CIPmask = 0x1fff03ff
[Jul 24 02:52:24] NOTICE[28076]: chan_capi.c:6007 cc_post_init_capi: Unused contr2
[Jul 24 02:52:24] NOTICE[28076]: chan_capi.c:6007 cc_post_init_capi: Unused contr3
[Jul 24 02:52:24] NOTICE[28076]: chan_capi.c:6007 cc_post_init_capi: Unused contr4
[Jul 24 02:52:24] NOTICE[28076]: chan_capi.c:6007 cc_post_init_capi: Unused contr5
  == Registered channel type 'CAPI' (Common ISDN API Driver (1.1.1))
  == Registered application 'capicommand'
chan_capi.so => (Common ISDN API Driver (1.1.1))
res_clioriginate.so => (Call origination from the CLI)
res_convert.so => (File format conversion CLI command)
  == Registered channel type 'Agent' (Call Agent Proxy Channel)
[Jul 24 02:52:24] NOTICE[28076]: chan_agent.c:1084 read_agent_config: No agent configuration found -- agent support disabled
...
...
unc_uri.so => (URI encode/decode dialplan functions)
Asterisk Ready.
  == ISDN1#02: Incoming call '' -> 'ô³^X^Hw^ð·^A'
[Jul 24 02:53:53] NOTICE[28090]: chan_capi.c:2576 start_pbx_on_match: ISDN1#02: did not find exten for 'ô³^X^Hw^ð·^A', ignoring call.

Jetzt fräg ich mich nur, warum die Nummer so merkwürdig angezeigt wird. Bin kein Asterisk-Experte. Zumindest liegt der Fehler in der libcapi20, da ich beim capi20_release auch gleichzeitig die Verbindung schließe (capi20_fb_tcp_close_socket). Das müsste ich ändern...

EDIT:
ich hab mal die geänderte Version angehangen. Die chan_capi.c habe ich auch etwas geändert. Das kannst du ja mit diff vergleichen. Das mit der Nummer ist noch merkwürdig... ich habe den Asterisk auch nicht komplett konfiguriert. Muss mal weiter schauen - zumindest erkennt er, dass es sich um einen eingehenden Anruf handelt. Also mit Endianess lag ich falsch, sonst würde garnix gehen.

EDIT:
Beim zweiten Anruf steht plötzlich die Nummer im Log. Mhh... Sehr merkwürdig.

 

[ozett]

et jeht. gelöst?

meyn jottt, et jeehhhhht, et jehhttt.
wunderbar. mod compiliert, chan_capi.so eingespielt und raustelefoniert (incoming-test später). soweit wunderbar, klappt.

asterisk läuft nur in eine vm und die fritzbox ist über ein openvpn erreichbar, daher leicht "choppy" sound. werde einen lan-test in den nächsten tagen folgen lassen, ob sich das verbessert. aber remote-capi scheint (erstmal) super zu funktionieren.

das war ne super unterstützung. danke, danke. :done:
mal sehen wozu der elan jetzt noch reicht, ich erwarte großes!

grüsse,
ozett

 

[bodega]

Heute auf jedenfall nicht mehr so sehr. Erwarte da mal nicht so viel

Eines steht auf jedenfall fest: es gibt noch ein Problem mit dem Zusammensetzen der Calling- und Called-Party-Number. Das muss irgendwo in capi_number(...) passieren.

Über die Remote-CAPI telefonieren geht ganz gut, jedoch habe ich das nicht mit dem Asterisk getestet.

 

[ozett]

so. neuer tag - neuer test.
raustelefonieren geht, aber es surrt dauerhaft in der leitung.
bei reinkommenden rufen ein fehler.

  == ISDN1#02: Incoming call '021234567' -> '123456'
  == ISDN1#02: CAPI Hangingup for PLCI=0x1801 in state 4

nach googlen fand ich jemanden, der keine 2 kanäle mit einer fritzbox 7050 belegen konnten. hoffentlich liegt die fehlerursache nicht allein an dem boxtypen (oder config?).

http://www.ip-phone-forum.de/archive/index.php/t-88847.html

grüsse,
ozett

 

[bodega]

Das surren in der Leitung könnte am alaw/pcm Converter liegen.
Die Sache mit den zwei B-Kanälen kann ich mir irgendwie schwer vorstellen. Der Statuscode, der nach dem Hangingup kommt, wäre interessant gewesen. Das kannst du auch mal mit der dtmfbox probieren um den Fehler einzugrenzen (wenn es an der Konfig/chan_capi liegen sollte).

EDIT:
Also bei mir funktioniert das auf der CLI:

originate CAPI/ISDN2/73....  application Dial CAPI/ISDN1/4......

ISDN2=Capi-Ctrl. 3 und ISDN1=Capi-Ctrl. 1.
Klar, wenn du dich selbst auf Ctrl. 1 anrufst, sind zwei B-Kanäle weg. Also einen für die ausgehende Verbindung, und einen für die Verbindung, welche wieder rein kommt. Das Surren bekomme ich auch...

EDIT2:
das Surren liegt wohl irgendwie am eingebauten Echo-Canceller. Ich hab ihn aus dem Code genommen. Zur Übersicht, habe ich die aktuelle chan_capi hier hochgeladen.

EDIT3:
habe mal den Wiki-Eintrag überarbeitet. capifax-0.3, libcapifax-0.4 hatte ich gestern aktualisiert.

 

[ozett]

hi,
super elan, und auch gute arbeit. ich tue mich etwas schwer mit dem hinweis, weil ich weiss, dass eben immer auch zeit und mühen hinter freiwilligen infos und updates stecken, aber mir als wiki-leser geht es häufig immer erstmal ein wenig um eine einfache schritt-für-schritt-anleitung zum erfolg. hier wäre es sicher an der stelle

Eine modifizierte chan_capi befindet sich ebenfalls im Forum. Damit sollte es möglich sein, den Asterisk mit der FB zu verbinden.

ein link auf die source oder den namen sicher hilfreich und lange suchen im forum zu verkürzen. :gruebel:

die neue version wird gleich mal kompiliert. tonquali-test allerdings erst später.
ps hatte zwei getrennte isdn-anschlüsse für raus- und einwahl als es zum fehler

CAPI Hangingup for PLCI=0x1801 in state 4

kam. Statuscode wird also nachgeliefert, genauswo ei ein test mit dmtfbox. guter anlass jetzt das mal auszuprobieren. sieht interessant aus...

grüsse,
ozett

 

[meiser79]

Hi,

hab mal capifax-0.3 getestet (mit libcapi20-fb-0.4). Es hängt bei "Phase E: coding method T.4 1-D" (Loglevel 1).
CapiSpFax funktioniert weiterhin prima.

Was für Infos bräuchtest Du noch, bodega?

Danke,
Whoopie

 

[WLAN-VoIP-Fan]

Hi,

könnte der Thread-Starter mal eine Zusammenfassung des bisherigen Standes geben bitte?

Danke.

 

[bodega]

ein link auf die source oder den namen sicher hilfreich und lange suchen im forum zu verkürzen

Wahrscheinlich. Der Link ist ja unter "Quellen" zu finden. Der Text ist momentan noch absichtlich kurz geraten. - das kommt alles noch...

hab mal capifax-0.3 getestet (mit libcapi20-fb-0.4). Es hängt bei "Phase E: coding method T.4 1-D" (Loglevel 1).
CapiSpFax funktioniert weiterhin prima.

Was für Infos bräuchtest Du noch, bodega?

Interessant. Weder in CapiSpFax noch in libcapifax wurde "T.4 1D" Kompression eingebaut (könnte man aber). Jetzt bist wohl du gefragt: Liegt es an spandsp 0.4/0.5? Das kann man als #define einstellen. Die Initialisierungsroutinen zum Fax machen in beiden Programmen genau das selbe. Schon ein anderes Faxgerät probiert? C++ Compiler (zwingend) verwenden???

 

[Groening]

Endlich eine Linux Lösung - Hut ab

Hallo,

ich habe versucht libcapi20_fb-0.4 bei mir zu testen, nur scheitere ich bereits am make, hier der Auszug, ist die neueste Version viel. broken?
(ohne jemandem nahe treten zu wollen, was ihr hier macht ist der Wahnwinn)
:groesste:

root@bla:/.../libcapi20_fb-0.4/libcapi20_fb-0.4/src# make
gcc  -DPACKAGE=\"libcapi20\" -DVERSION=\"\" -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LINUX_CAPI_H=1 -DHAVE_SELECT=1   -I. -I. -c capifunc.c -o capifunc.o 
In file included from capifunc.c:42:
capi20.h:63: Fehler: expected declaration specifiers or »...« before »size_t«
capi20.h:64: Fehler: expected declaration specifiers or »...« before »size_t«
make: *** [capifunc.o] Fehler 1

System: Ubuntu Hardy x86 (2.6.24-19-generic)

Wer schön, wenn mir jemand bei der Installation weiterhelfen würde, ich würde gerne als weiterer Testnutzer einsteigen und das ganze inkl. GTK Frontend und CUPS Drucker bis ins Letzte austesten...

Sollte das erfolgreich laufen, würde ich mit eurer Erlaubnis im Forum bei ubuntuusers.de weitere Nutzer suchen und das Projekt dort voran treiben, seit Jahren habe ich dort in allen Foren mitgemischt, wo es um den Einsatz von nativer FritzBoxen zum Versenden von Faxen ging und dort Kontakt zu vielen potenziellen Nutzern geknüpft.

Wenn sich da was tut, würde ich es an euch weitergeben (wenn ihr wollt)...

Wenns denn stable ist, fänden sich sicher auch Leute, die bereit wären ein .deb für x86-Maschinen zu erstellen (immer unter der Voraussetzung, dass neben der Fritzbox keine weitere FritzCard im System verbaut ist)