Bezahlbares GSM-VoIP-Gateway auf Asterisk-Basis zum selber bauen

[schufti]

@Kettenring:
welche asterisk Version hast du?

chan_datacard Rev50 braucht mind 1.6.1.18 oder 1.6.2.6

dann sollte chan_datacard.so beim laden die geforderte Funktion "utf8_to_hexstr_ucs2" auch finden ....

es könnte aber auch sein, dass du bei der Auswahl der Module das deaktiviert hast, wo "utf8_to_hexstr_ucs2" drinne ist ....


schufti

[Kettenring]

welche asterisk Version hast du?

chan_datacard Rev50 braucht mind 1.6.1.18 oder 1.6.2.6

Ich habe auf beiden Servern die Asteriskversion 1.6.2.6 installiert.

dann sollte chan_datacard.so beim laden die geforderte Funktion "utf8_to_hexstr_ucs2" auch finden ....

es könnte aber auch sein, dass du bei der Auswahl der Module das deaktiviert hast, wo "utf8_to_hexstr_ucs2" drinne ist ....

Die Funktion scheint allerdings nicht gefunden zu werden. Sagen wir mal so, ich wüsste nicht wann und wie ich die Funktion deaktiviert haben sollte. Ich habe das Paket für Asterisk direkt von asterisk.org in der aktuellsten Release verwendet.


Wo bekomme ich denn eine ältere Revisoion der 'chan_datacard' her? Kann mir die jemand von Euch zukommen lassen? Vielleicht funktioniert es ja damit einfach.

[voipalex]

@Fredjam
Hast du schon eine Lösung für das Disconnecten des Sticks gefunden. Meiner ist immer so nach ca. 10 Stunden nicht mehr da, d.h. ich habe keine ttyUSB Ports mehr und kann ihn auch nicht mehr mit lsusb finden. Muss ihn dann auch aus- und wieder einstecken.

Dieser Post wurde bisher gar nicht beachtet.

Zunächst möche ich mal bestätigen, dass ich das gleiche Problem habe mit unterschiedlichen Setups. Dieses Problem ist wohl unabhängig von chan_datacard und ich habe dafür bisher keine Lösung gefunden.

Siehe dazu auch mein Post im Huawei Support Forum: http://forum.huawei.com/jive4/thread...hreadID=330907

Hat jemand von euch schon ähnliches beobachtet? Da das Problem bei mir unter Umständen erst nach Tagen auftritt, wäre ich für Aussagen zu Langzeiterfahrungen dankbar.

Der Entwickler von chan_datacard (Artem) sieht dieses Problem übrigens nicht mit seinen Sticks. Evtl haben alle meine Sticks eine Macke. Jedoch sehe ich das Problem mit 3 (!) baugleichen K3520 und identischem Firmwarestand.

Gruß
Alex

[Tippfehler]

Dieses Problem hatte ich auch. Ich lese hier natürlich ständig mit und hoffe auf eine Lösung dieses Problems, denn so mußte der Stick wieder dem MV-370 weichen.
Vielleicht hilft es, wenn man eine ältere Firmware auf die Fritzbox macht.
---Edit---
Habe erst später gesehen, dass Du die Probleme auf einem PC hast.

[chrizzz]

Hallo! Super Anleitung hier! Hab ein Problem mit dem Providernamen, da steht bei mir nur FFFFFFFFF. Benutze eine EPlus-Karte und bisher funktioniert alles andere Klasse

[PsychoMantis]

Ich hatte bisher Vodafone, o2 und BASE ausprobiert und in allen drei Fällen stand da der Providername.
Aber das Anzeigen des Providernamens...dieses "Feature" ist ja wohl unwichtig.
EDIT: Aussage zurückgezogen. ich1234 meint mit dem Beitrag unter diesem wohl das hier.

[ich1234]

Wohl eher nicht. Ich möchte zum Beispiel mit meiner T-Mobile Karte nicht im Ausland eingebucht sein, wenn ich per Asterisk Gespräche rüberschicke. Deshalb hab ich auch den Quellcode umgeschrieben, siehe weiter oben.

[Fredjam]

die page ist wieder online

https://www.makhutov.org/svn/chan_datacard/trunk/

Da hier im moment viele probleme habe mit disconnects usw, sollten wir vielleicht mal jeder posten, welches OS (System) und welche weitere konstelation jeder von uns hat.

ich nutzte ein Linux debian 2.6.26-2-686
mit Asterisk 1.6.2.6 und chan_datacard - Revision 50
UMTS Stick - K3520 x 10, hier bei ist zu sagen das ich drei verschiedene Firmware auf den sticks habe.

Weitere Hardware:
Sedna SE-USB-HUB-113A-B (hier bei ist zu sagen das ich 6 USB Hubs durchgetest habe. Hier bei waren durchgehend schlechte ergebnisse zu sehen. Verbindungsabbrüche, Disconnect usw..)

meine udev rulz um zu unterscheiden welcher stick welcher ist.

SUBSYSTEMS=="usb", SYMLINK+="ttyUSB_%b", KERNEL=="ttyUSB*", MODE="0666", OWNER="asterisk",GROUP="uucp"

Meine Probleme sind:
irgend wann kann ich keine sms mehr empfangen.
Wenn ich zu viel mit CUSD rumgespielt habe funktionieren diese auch nicht mehr.

Disconnects auf längere zeit. Aber auch nicht bei allen....
Hier bei werde ich im laufe der woche noch genauer drauf achten. Welche Stick diese das Problem habe.
Da alle an einem USB hub angeschlossen sind, kann ich gut nachvolllziehen ob es vielleicht sogar am usb hub liegt.

EDIT:
Bei dem Ausfähren von:
CLI> datacard cusd 16 *100#
habe ich das hier bekommen...

2010-04-08 22:14:30 - Datacard/16-5a7f: 00200041006B007400750065006C006C0065007300200047007500740068006100620065006E003A002000310033002E003900370020004500550052002E",0

^BOOT:35089969,0,0,0,72

OK

+CUSD: 0,"00490068007200650020005200750066006E0075006D006D0065007200200069007300740020003000310035003100320036003300340039003200350030002E

Ich habe eine Extra Card von T-mobile...

Das CUSD problem hat sich erledigt Nice work Artem.

Rev 53:
Removed workaround for parsing multiline cusd messages because we get them as Hex encoded UCS-2 messages now.
This should also resolve some problems where incoming cusd messages were not parsed properly.
Rev 52:
Removed manufacturer from datacard show devices
Rev 51:
*added functions to parse AT+CSQ and update the signal strength more frequently
*added option to disable ATZ during initialization
*added option to set U2DIAG mode during initialization
*added functions to read the subscribers phone number (if stored on SIM card)

kann man jetzt eigendlich außer über "datacard show devices" die eigene Handynummer auslesen?

Letzter fehler den ich mut CUSD hatte

datacard cusd 1 *100#
 Got CUSD response from device 1: 00200041006B007400750065006C006C0065007300200047007500740068006100620065006E003A002000310035002E003000350020004500550052002E
  == Starting Datacard/1-ce64 at datacard-incomings,cusd,1 failed so falling back to exten 's'
  == Starting Datacard/1-ce64 at datacard-incomings,s,1 still failed so falling back to context 'default'
    -- Executing [s@default:1] Playback("Datacard/1-ce64", "vm-goodbye") in new stack
    -- <Datacard/1-ce64> Playing 'vm-goodbye.gsm' (language 'en')
    -- Executing [s@default:2] Macro("Datacard/1-ce64", "hangupcall") in new stack

[chrizzz]

Ich kriegs einfach nicht hin, die chan_datacard auf dem openWRT laufen zu lassen.

Ich habe mir selbst ein openWRT-Image kompiliert inkl. dem Asterisk (auf einem Debian-System mit installiertem Asterisk). Dann kann ich mit dem Makefile aus dem ersten Post chan_datacard kompilieren. Wenn ich die .so aber rüberkopiere, funktioniert das nicht. Zum einen fehlen zwei Funktionen zum konvertieren von udf<->ucs für die SMS-Funktion. Das kann man umgehen, indem die chan_datacard.c bearbeitet wird (dann natürlich kein sms mehr möglich).
Wenn ich dies tue komme ich zum zweiten Problem: Der * läd das Modul nicht, da es mit anderen "Compile-Time Options" kompiliert wurde... Es gibt ja keine Möglichkeit, den * direkt auf openWRT zu kompilieren!? Gruß, Christian

[PsychoMantis]

Da es mit OpenWRT Probleme gibt/gab, habe ich versucht es direkt unter voyage (eine Art debian) zu kompilieren. Asterisk und chan_datacard wurden zwar kompiliert, aber aus irgendeinem Grund kann chan_datacard nicht geladen werden:

*CLI> module load chan_datacard.so
Unable to load module chan_datacard.so
Command 'module load chan_datacard.so ' failed.
*CLI> [Apr 12 00:08:11] WARNING[18482]: loader.c:428 load_dynamic_module: Error 
loading module 'chan_datacard.so': /usr/lib/asterisk/modules/chan_datacard.so: 
undefined symbol: utf8_to_hexstr_ucs2
[Apr 12 00:08:11] WARNING[18482]: loader.c:794 load_resource: Module 
'chan_datacard.so' could not be loaded.

Diese Fehlermeldung mir so anschauend, dachte ich, dass noch irgendeine library fehlt. Ich habe daraufhin versucht noch einige per apt-get zu installieren, aber die Fehlermeldung ist geblieben.
Ideen?

[Kettenring]

Asterisk und chan_datacard wurden zwar kompiliert, aber aus irgendeinem Grund kann chan_datacard nicht geladen werden:

Wenn Du mal hier liest ist das soweit ich das sehe der gleiche Fehler. Ich habe bis jetzt leider noch keine Lösung gefunden. Welche Version der chan_datacard verwendest Du denn? Ich habe gestern gesehen, dass es die Rev53 gibt. Ich habe es bis jetzt nur mit der Rev50 versucht, da mir leider keiner eine ältere Version zukommen lassen hat.

[chrizzz]

Die beiden Funktionen utf8_to_hexstr_ucs2 und hexstr_ucs2_to_utf8 sind nicht implementiert. Ich würde da eher auf eine fehlende Komponente in Asterisk tippen.. Die sind übrigens zur Konvertierung für SMS. Wer das noch nicht braucht, kann in der chan_datacard.c nach den Funktionen suchen, und den Wert auf 0 setzen. Die folgende if-Abfrage ist so immer erfüllt und schreibt bei ankommender SMS einen Fehler ins Log.

Besser fände ich es, direkt auf dem Alix Board zu kompilieren. Dafür versuche ich seit zwei Tagen gcc zu kompilieren... Dafür habe ich (aus dem Buildroot) das Makefile aus

../backfire/feeds/packages/devel/gcc

nach

../backfire/package/gcc

kopiert und die .config angepasst

PACKAGE_gcc=y

oder so ähnlich unten angefügt. Danach führe ich ein

make package/gcc-compile

aus. Unter Ubuntu mit exakt der gleichen Vorgehensweise ging es nicht, unter Debian wird ewig kompiliert, die toolchain wird erstellt usw. aber es dauert ewig... und GNOME stürzt zeitweilig ab.

Falls gcc läuft, könnte man sicher auch * direkt kompilieren, das würde die Sache ja extrem vereinfachen, die benötigten Libs sind ja alle verfügbar, soweit ich das überblicken kann!

P.S.: Ich benutze * 1.6.2.6, in Debian + openWRT, dazu chan_datacard rev53

EDIT

Da es mit OpenWRT Probleme gibt/gab, habe ich versucht es direkt unter voyage (eine Art debian) zu kompilieren. Asterisk und chan_datacard wurden zwar kompiliert, aber aus irgendeinem Grund kann chan_datacard nicht geladen werden:

Wie hast du es denn geschafft, den auf voyage kompilierten Asterisk auf openWRT zu kriegen? Einfach die Dateien kopiert?

[PsychoMantis]

@ Kettenring
Hol dir einfach eine ältere Version mit

svn co http://www.makhutov.org/svn/chan_datacard/trunk/@37

wenn du es noch brauchst.

@ chrizzz
Nein, nicht rüberkopieren. Einfach ganz normal unter Debian oder sonst was das OpenWRT bauen mit Asterisk und alles drum und dran. Aber da habe ich auch diese Probleme mit diesen Konvertierungen der SMS. Wo genau ist das im code vergraben? Oder besser wie kann man die von dir angesprochenen Fehlenden Komponenten hinzufügen?

[chrizzz]

Wohin kopierst du denn die chan_datacard Source? Das Problem mit den UTF-Funktionen wird der Entwickler sicher selbst lösen... Ansonsten müsste man selbst was vergleichbares schreiben, vllt mit SED oder so!? Damit du es kompilieren kannst, musst du nach den Funktionen suchen und die variable auf 0 setzen. Also z.b. Von

var=utf-to-u...

zu

var=0;//utf-to...

sorry schreib gerade vom handy

[PsychoMantis]

Die Sourcen schmeiße ich einfach in den asterisk/channels - Ordner rein, bevor ich anfange Asterisk zu kompilieren (bzw. OpenWRT mit Asterisk).
Wie gesagt, klappt es aber momentan nicht in OpenWRT (aber auch nicht in voyage) wegen diese UTF-Sache. Mit Rev. 37 hat alles aber noch funktioniert (da haben die sourcen von chan_datacard aber auch nur aus der einen Datei chan_datacard.c bestanden).

[chrizzz]

Hier mal die angepasste chan_datacard.c

ANMERKUNG: Damit wird SMS nicht funktionieren, weitere Probleme sollte es aber nicht geben. Das ist nur die TEMPORÄRE Lösung! Rev53

[PsychoMantis]

Danke, das scheint zu funktionieren (noch kein Gespräch drüber geführt, aber wird immerhin geladen):

voyage*CLI> datacard show devices
ID              Group  Connected State Voice SMS   RSSI  Mode  Submode Provider Name   Model      Firmware          IMEI              Number
datacard2       1      Yes       Free  Yes   Yes   28    0     0       Vodafone.de     K3520      11.314.21.31.00   xxxxxxxxxxxxxxx   Unknown
datacard1       2      Yes       Free  Yes   Yes   30    0     0       BASE DE         K3520      11.314.21.31.00   xxxxxxxxxxxxxxx   Unknown
datacard0       1      Yes       Free  Yes   Yes   27    0     0       Vodafone.de     K3520      11.314.21.31.00   xxxxxxxxxxxxxxx   Unknown
voyage*CLI>

SMS sind mir vorerst egal.

[chrizzz]

Wie hast du denn jetzt asterisk kompiliert? Hab die Sourcen von chan_datacard in

..build_dir/target-i386_uClibc-0.9.30.1/asterisk-1.6.2.6/channels

und dann versucht

make package/asterisk-1.6-compile

auszuführen... Geht aber natürlich nicht. Oder hast du das gesamte Ding kompiliert? Dauert ja ewig... Wärst du so nett und schickst mir deine asterisk*.ipk (alle die du kompiliert hast) aus dem Verzeichnis

../bin/x86/packages

[PsychoMantis]

Ja, ich hatte damals mit make menuconfig Asterisk ausgewählt und mit make das ganze openwrt samt Asterisk kompiliert. Sorry, habe die Dateien nicht mehr Höchstens im Anhang des ersten Posts dieses Threads ist eine veraltete chan_datacard.so (im Image drin) für eine ältere Asterisk-Version.

[schufti]

Hi chrizzz,

die Funktionen sind doch in char_conv.c, warum also den Source verstümmeln. Schau lieber, warum die char_conv.c nicht compiliert und zu chan_datacard gelinkt wird. Zur Not kannst du ja die Funktionen aus der char_conv.c in die chan_datacard.c kopieren ....

schufti