[HowTo] Bezahlbares GSM-VoIP-Gateway auf Asterisk-Basis zum selber bauen

*** hochschupsen ***

Hallo alle,

wie ist das denn bei Euch, sind da die Sticks am Asterisken immer stabil? Bootet Ihr regelmäßig neu oder wie umgeht Ihr das Problem, daß sich die Sticks weghängen? Bei mir "hält" das System etwa 3-4 Tage und dann beklagt er sich, daß das AT-Kommando nicht ankommt...

Bitte bringt mal Beistand, mir gehen die Ideen aus...

Hawedieehre.
Fant.

P.S.: @PsychoMantis: Ja, ich weiß, keine zwei Beiträge hintereinander. Aber offenbar wird die Änderung eines Beitrags bei den Abonnenten des Topics nicht signalisiert. Und daher dachte ich... ;-)
 
Das stimmt: Änderung eines Beitrages wird nicht signalisiert. Ich mache das immer so, dass ich einen neuen erstelle und den alten davor entweder lösche oder in den neuen (letzteren) hinzufüge.
Zu deinem Problem: Bei mir hängt sich wochenlang nichts mehr auf, seit ich dem USB-Hub saubere, vom restlichen System galvanisch getrennte 5V DC zuführe.
Davor hatte ich auch alle paar Tage das Problem, dass irgendein Stick sich aufhängt. Der Programmierer von chan_dongle hat mir dann geraten die UMTS-Sticks mit sauberer und stabiler Spannung zu versorgen. Ich hielt das für Blödsinn, weil ich dachte, dass es schon so passt wie es ist. Aber nach Umlöten + Basteln ist alles richtig stabil.
 
Ich nutze den günstigen DeLock USB2.0 Hub und speise den nur über den Rechner, mache jedoch mit einem Script periodisch ein Reboot (3:01 Uhr Nachts)

Anbei das Script:
Code:
#!/bin/bash

LOGFILE="/var/log/restart_dongle.log"


echo "[RESTART_DONGLE] Detecting USB Hub"
UHUBBUS=`lsusb | grep "Genesys Logic, Inc. USB-2.0 4-Port HUB" | cut -d" " -f 2`
UHUBDEV=`lsusb | grep "Genesys Logic, Inc. USB-2.0 4-Port HUB" | cut -d" " -f 4 | cut -d":" -f1`

echo "[RESTART_DONGLE] BUS <$UHUBBUS> und DEVICE <$UHUBDEV> erkannt."
date >> $LOGFILE
echo " BUS <$UHUBBUS> und DEVICE <$UHUBDEV> erkannt." >> $LOGFILE


echo "[RESTART_DONGLE] Restarting UMTS Modem..."
date >> $LOGFILE
echo "Vorher:" >> $LOGFILE
lsusb >> $LOGFILE

echo "[RESTART_DONGLE] Powering Off UMTS Modem..."
# Powering Off the Dongle
/root/hub-ctrl -b $UHUBBUS -d $UHUBDEV -P 4 -p

sleep 5

echo "Nachher:" >> $LOGFILE
lsusb >> $LOGFILE

echo "[RESTART_DONGLE] Powering On UMTS Modem..."
# Powering on the Dongle
/root/hub-ctrl -b $UHUBBUS -d $UHUBDEV -P 4 -p 1

sleep 15

echo "Nach Reboot:" >> $LOGFILE
lsusb >> $LOGFILE

date >> $LOGFILE
echo "Restarting UMTS Modem done!"  >> $LOGFILE
echo "Restarting UMTS Modem done!"

Verbesserungsvorschläge und Tipps sind natürlich jederzeit herzlich willkommen.
 
Zuletzt bearbeitet:
@klassenblatt: Danke, aber mir fehlt leider das hub-ctrl, das in Deinem Skript aufgerufen wird. Ist das ein Binary File oder ein Skript?? Poste doch mal bitte...

Hawedieehre.
Fant.
 
@Fant: hub-ctrl ist ein kleines Tool, welchen man selbst kompilieren muss (wird weiter vorne beschrieben)

Ich habe die Sourcefile die ich genutzt habe mal angehängt.

Ich hab auch noch eine Bitte an alle, die sich mit Bash auskennen: Könnt ihr mir helfen, das Script bezüglich Logging zu Optimieren?

Anhang anzeigen hub-ctrl.zip
 
Zuletzt bearbeitet:
Hi,

bei mir rennt der Huawei 1550 nun seit gut 2-3 Monaten durchgehend (24/7) ohne Probleme.
(Vielen Dank an alle die das ermöglicht haben!!!)

Doch auf ein Problem bin ich gestossen:
Heute die erste Multipart-SMS bekommen, die gänzlich unleserlich ist. Ich dachte die wird einfach aufgeteilt und in der zweiten SMS geht der Text ganz normal weiter. Scheint falsch zu sein, da dürfte es noch irgendein encoding oder sowas geben, was besagt dass es eine längere SMS ist.
Nur wie parsen bzw wie in der Asterisk einlesen?

Beispiel Log-Auszug:
[privatone] Got SMS from +43660xxxxxxx: 'GQAPCEA\_GQAJS]A`CCeS]OKANYKSGQAR]AHKeA
e}QAtkADKg_eOK]Y@nK]]gAHSeAdKGQiARgiAn}eIARGQANKe]AJegiAj[ArPg`@heKMMK]Y@HSeKWiAB[AeiAHKgAKgGQKQK]gu@$_iK]ik'
-- Executing [sms@default:1] Verbose("Local/sms@default-16b5;1", "Incoming SMS from +43660xxxxxxx GQAPCEA\_GQAJS]A`CCeS]OKANYKSGQAR]AHKeA
e}QAtkADKg_eOK]Y@nK]]gAHSeAdKGQiARgiAn}eIARGQANKe]AJegiAj[ArPg`@heKMMK]Y@HSeKWiAB[AeiAHKgAKgGQKQK]gu@$_iK]ik") in new stack
Incoming SMS from +43660xxxxxxx GQAPCEA_GQAJS]A`CCeS]OKANYKSGQAR]AHKeA
e}QAtkADKg_eOK]Y@nK]]gAHSeAdKGQiARgiAn}eIARGQANKe]AJegiAj[ArPg`@heKMMK]Y@HSeKWiAB[AeiAHKgAKgGQKQK]gu@$_iK]ik
-- Executing [sms@default:2] System("Local/sms@default-16b5;1", "sh /var/lib/asterisk/send_mail.sh 'privatone' '+43660xxxxxxx' 'GQAPCEA\_GQAJS]A`CCeS]OKANYKSGQAR]AHKeA
e}QAtkADKg_eOK]Y@nK]]gAHSeAdKGQiARgiAn}eIARGQANKe]AJegiAj[ArPg`@heKMMK]Y@HSeKWiAB[AeiAHKgAKgGQKQK]gu@$_iK]ik' ") in new stack
-- Executing [sms@default:3] Hangup("Local/sms@default-16b5;1", "") in new stack
== Spawn extension (default, sms, 3) exited non-zero on 'Local/sms@default-16b5;1'

(Ist keine geheime SMS, den Inhalt konnte ich am Handy (SMS ging gleichzeitig an VoIPgw+Handy) normal lesen.
Oder fehlt irgendwo ein Mime-Enconding oder sowas?

Bitte um Hilfe! :)

LG

PS.:
Die erste SMS kam übers Asterisk so an:
d[gieCggKAblZbpX@}e_Ab`[email protected]]]giADKSAKOK]gaeKGQADSgiY@dSMAZSGQAB]C
Die zweite so:
GQAPCEA_GQAJS]A`CCeAS]OKANYKSGQAR]AHKeA

Dialplan in extensions.conf:
exten => sms,1,Verbose(Incoming SMS from ${CALLERID(num)} ${BASE64_DECODE(${SMS_BASE64})})
exten => sms,n,System(sh /var/lib/asterisk/send_mail.sh '${DONGLENAME}' '${CALLERID(num)}' '${BASE64_DECODE(${SMS_BASE64})}' )
exten => sms,n,Hangup()
 
Zuletzt bearbeitet:
Also irgendwas geht da mit smsaspdu=yes in dongle.conf und im Dialplan kann man mit Base64 da irgendwas umwandeln. Ist eine heikle Geschichte.
Problem ist, dass sich niemand um die SMS-Unterstützung gekümmert hat.
Momentan kümmern sich um dieses Projekt insgesamt keiner mehr. Der erste Entwickler (Makhutov) macht hier schon seit Jahren nix mehr, und der andere (bg1) ist seit über einem Jahr auch still und macht so gut wie nichts mehr.
 
Unschön zu hören :(

Meine aktuelle dongle.conf:
[general]

interval=15
;jbenable = yes
;jbforce = no
;jbmaxsize = 200
;jbresyncthreshold = 1000
;jbimpl = fixed
;jbtargetextra = 40
;jblog = no
[defaults]
context=default
group=0
rxgain=0
txgain=0
autodeletesms=yes
resetdongle=yes
u2diag=-1
usecallingpres=yes
callingpres=allowed_passed_screen
disablesms=no
smsaspdu=yes
language=en
mindtmfgap=45
mindtmfduration=80
mindtmfinterval=200
callwaiting=auto
disable=no
exten=+1234567890
dtmf=relax

Welche Möglichkeiten habe ich sonst noch? Was müsste ich lernen um da weiter machen zu können wo vor Jahren aufgehört worden ist? ;)

Wollte mir den source ansehen und bemerkt dass es eine "neuere" Version gibt:

chan_dongle version 1.1 revision 14 sources
Uploaded by: [email protected]
Released: Oct 12, 2012
Uploaded: Oct 12, 2012

Doch auch mit dieser leider keine Verbesserung.
Interessant:
189064 Jun 26 00:17 chan_dongle.so (altes modul)
895878 Nov 9 17:28 chan_dongle.so (neues modul)
 
Zuletzt bearbeitet:
Was du lernen müsstest? Die Programmiersprache "C".
 
Wie IMEI eines Huawei UMTS-Sticks ändern?

Es ist bereits bekannt, dass man die IMEI ändern kann. Es gibt einige Methode. Eine davon funktioniert so, dass in einem Firmware-Update (exe-Datei) paar Bytes umgeschrieben werden und dann man ganz normal die Firmware flasht. Danach hat der Huawei-UMTS-Stick eine neue IMEI.
Ich habe mir im Internet fünf solche Beispiel-"firmware-updates" runtergeladen und sie mit UltraCompare verglichen. Die sind fast gleich.
Sieht so aus:
Code:
IMEI			erster Unterschied		zweiter Unterschied
353237839847796		3A 35 32 87 93 48 77 69		0B 57
353238856958110		3A 35 32 88 65 59 18 01		4A 9A	
353240999626778		3A 35 42 90 99 26 76 87		7D E5
353241209784548		3A 35 42 21 90 87 54 84		77 69
353237625100038		3A 35 32 67 52 01 00 83		8A 3D
Die Dateien unterscheiden sich vom Originalfirmwareupdate also nur in zwei Stellen. Die erste Stelle ist klar: hier steht die IMEI byteweise umgedreht.
Doch was ist die zweite Stelle? Diese zwei Bytes scheint irgendeine Prüfziffer zu sein. Diese zwei Bytes müssen irgendwie aus der IMEI generiert werden.
Ich verstehe nur nicht wie. Hat vielleicht jemand eine Idee?
 
FB 7170 - UMTS Stick (E1750c) nicht in chan_dongle Liste > ggf. moint point falsch?

Hallo Zusammen,

habe auf der 7170 mit freetz-devel 9715 und USB-root
Asterisk 1.6.2.23 + chan_dongle (http://freetz.org/attachment/ticket/706/asterisk_1.6.2.23_chan_capi_dongle_26.patch + http://freetz.org/attachment/ticket/706/asterisk_no_resolv.patch)
aus dem entsprechenden Ticket auf die Box geflasht. >> Danke waldoo

Der UMTS Stick (Alice UMTS-Stick 4 = Huawei E1750c) an einem aktiven USB2.0 HUB wird in den USB devices gelistet:
Code:
cat /proc/bus/usb/devices

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 1
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 0.00
S:  Product=USB AHCI Root Hub
S:  SerialNumber=be008000
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=255ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 4
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=05e3 ProdID=0608 Rev=77.60
S:  Product=USB2.0 Hub
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=255ms

T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=058f ProdID=6331 Rev= 1.20
S:  Manufacturer=Generic
S:  Product=Mass Storage Device
S:  SerialNumber=058F091111B
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#=  4 Spd=12  MxCh= 4
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=05e3 ProdID=0608 Rev=77.60
S:  Product=USB2.0 Hub
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=255ms

T:  Bus=01 Lev=03 Prnt=04 Port=02 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=1001 Rev= 0.00
S:  Manufacturer=HUAWEI Technology
S:  Product=HUAWEI Mobile
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

asterisk -rx "dongle show devices" gibt allerdings nur folgendes zurück:
Code:
ID           Group State      RSSI Mode Submode Provider Name  Model      Firmware          IMEI             IMSI             Number
dongle0      0     Not connec 0    0    0       NONE                                                                          Unknown

Hat jemand eine Idee, warum der Stick nicht in der chan_dongle Liste auftaucht und was ggf. zu tun ist, um den Stick ans laufen zu bekommen?

Vielen Dank schon einmal im voraus.

bye morT
 
Zunächst ist da die Frage, ob der Stick unter /dev/ttyUSB0 gelistet ist. Was sagt "ls -la /dev/ttyUSB*"?
Dann muss natürlich die dongle.conf stimmen (also der richtige Pfad zum UMTS-Stick dort stehen).
 
Also aus "ls -la /dev/ttyUSB*" werd ich nicht wirklich schlau.
Ich habe übrigens neben dem
- Stick (SD-card und CD-ROM deaktiviert) noch einen
- Card Reader (2 Partitionen: VAT, Ext3 (für USB-root))
am USB-hub hängen.

Code:
ls -la /dev/ttyUSB*
crw-rw-rw-    1 root     root      188,   0 Jan  1  2000 /dev/ttyUSB0
crw-rw-rw-    1 root     root      188,   1 Jan  1  2000 /dev/ttyUSB1
crw-rw-rw-    1 root     root      188,   2 Jan  1  2000 /dev/ttyUSB2
crw-rw-rw-    1 root     root      188,   3 Jan  1  2000 /dev/ttyUSB3

Wie kann ich daraus erkennen, welchen Pfad ich in die dongle.conf eintragen muss?
Du meinst folgenden Part, richtig?
Code:
; dongle required settings
[dongle0]
audio=/dev/ttyUSB1		; tty port for audio connection; 	no default value
data=/dev/ttyUSB2		; tty port for AT commands; 		no default value
 
Dann muss natürlich die dongle.conf stimmen (also der richtige Pfad zum UMTS-Stick dort stehen).

Bzw. reicht es auch wenn man die korrekte IMEI und/oder IMSI in der dongle.conf definiert (und die Zeile mit der Device-Angabe entfernt bzw kommentiert), chan_dongle erkennt daran das richtige /dev/ttyUSB*

edit: Beispiel:
[dongle0]
imei=123456789012345
imsi=123456789012345
[teststick]
; Testumgebung mit wechselnder SIM-Karte, daher keine IMSI Angabe
imei=123456789012345
;imsi=
 
Zuletzt bearbeitet:
[teststick]
; testumgebung mit wechselnder simkarte, daher keine imsi angabe
imei=123456789012345
;imsi=

Danke Dir. Manchmal müßte man einfach nur lesen. Daher mache ich für heute Schluss.

Leider hab ich mit dem teststick-Beispiel mit korrekter IMEI keinen Erfolg gehabt.
Immer noch
Code:
asterisk -rx "dongle show devices"
ID           Group State      RSSI Mode Submode Provider Name  Model      Firmware          IMEI             IMSI             Number
dongle0      0     Not connec 0    0    0       NONE                                                                          Unknown

Der Stick scheint ja vom System erkannt zu werden.
Warum ist der Stick dann nicht in der device list?
 
Der Stick scheint ja vom System erkannt zu werden.
Warum ist der Stick dann nicht in der device list?

Steck mal alle anderen USB-Geräte ab und nur den Dongle an, schau ob du dann Geräte unter /dev/ttyUSB* hast.


P: Vendor=12d1 ProdID=1001 Rev= 0.00
S: Manufacturer=HUAWEI Technology

Bin mir da nicht sicher wie das bei deinem Model ist, ob das auch supported ist usw; wenn ja, ist der Dongle im richtigen Modus? (evtl Syslog oder so schaun ob usb_modeswitch geschalten hat)

Meine beiden E1550 Dongles werden nach dem usb_modeswitch so angezeigt:
Bus 001 Device 087: ID 12d1:140c Huawei Technologies Co., Ltd.
Bus 001 Device 088: ID 12d1:140c Huawei Technologies Co., Ltd.
 
Zuletzt bearbeitet:
kannst du vielleicht auch mal kurz mit dem huawei mobile partner unter windows ein Testcall damit machen?
Z.b mit Mobile Partner 21.003.27.00.03 kannst du Telefonieren.
=> bitte keine FW flashen, sondern die mobile partner setup datei installieren.

dann fällt mir noch ein nach den Prozessen zu sehen. Nicht dass ein anderer Dienst Zugriff auf die TTYs hat und somit blockiert sind.
Blinkt die Stick LED oder leuchtet sie dauerhaft?

könnte das daran liegen?
http://code.google.com/p/asterisk-chan-dongle/source/detail?r=28
Changed Paths:
Modify /trunk/configure.in
Modify /trunk/pdiscovery.c
added E1750 port discovery (issue 100)

Bitte die version 28 auschecken und compilieren...
 
Zuletzt bearbeitet:
Huawei E1750 an FB7170

Ich hab den UMTS Stick an der FB7170 und zusammen mit Asterisk zum laufen bekommen - so lala ...

Allerdings verliert der Asterisk kurz nach Verbindungsaufbau den Kontakt zum dongle/Stick.
Nach ein paar Sekunden ist dieser wieder verfügbar.

Vermutungen
  • schlechter Empfang im Keller killt die Verbindung (allerdings läuft eine Sagem RL ohne Probleme)
  • der verwendete aktive USB 2.0 Hub liefert nicht genug Leistung obwohl das Netzteil etwas anderes sagt (muss ich mal messen)
  • der USB 1.1 Host ist doch zu schwach (will ich aber eigentlich bei Nutzung von GSM-Codec nicht glauben)
  • andere Ideen?

Schritte zum "Erfolg" > Danke waldoo nochmal
  • mit cat /proc/bus/usb/devices feststellen, dass der UMTS Stick keine Treiber geladen hat
Code:
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  [B][COLOR="#FF0000"]Vendor=12d1 ProdID=1001[/COLOR][/B] Rev= 0.00
S:  Manufacturer=HUAWEI Technology
S:  Product=HUAWEI Mobile
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff [B][COLOR="#FF0000"]Driver=(none)[/COLOR][/B]
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff [B][COLOR="#FF0000"]Driver=(none)[/COLOR][/B]
E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff [B][COLOR="#FF0000"]Driver=(none)[/COLOR][/B]
E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
  • mit lsmod feststellen, dass die Kernelmodule "usbserial" und "option" tatsächlich nicht geladen wurden
  • nachladen der Kernelmodule (irgendwo hier im Forum gefunden)
Code:
modprobe usbserial vendor=12d1 product=1001 [COLOR="#FF0000"]>> siehe dazu die IDs nach Ausgabe cat /proc/bus/usb/devices[/COLOR]
modprobe option
  • mit lsmod und "cat /proc/bus/usb/devices" vergewissern, dass die Module geladen sind/der Stick die Treiber zugewiesen bekommen hat
  • dann weiter wie im ersten Post beschrieben > Danke PsychoMantis


Anmerkungen
  • bei mir hat die Identifizierung des Stick in der dongle.conf nur über die IMEI nicht funktioniert > es wurde kein device erkannt
  • identisches Verhalten habe ich auch mit einem Huawei K3765

Hat jemand Ideen, wie das ganze doch noch funktionieren kann?

Danke

bye morT
 
Zuletzt bearbeitet:
An einer 7170er ist das ganze eh problematisch, weil nur USB 1.1 vorhanden ist. Auch an anderen Fritzboxen (7270er, 7390er) habe ich es nie zufriedenstellend zum Laufen gebracht.
Nahezu zufrieden bin ich nur an einer Linux-Machine, die ausschließlich nur für Asterisk und chan_dongle verwendet wird.

Auf meinem Alix-Board läuft eigentlich alles perfekt, bis auf ein Problem: Nach einigen Stunden oder Tagen Laufzeit gibt es plötzlich Stille (nur in eine Richtung oder auch in beide). "module unload chan_dongle.so" und dann "module load chan_dongle.so" bringt nichts. Mit einem "core restart now" ist das Problem dann aber beseitigt. So wie ich das sehe, ist das Zusammenspiel zwischen chan_dongle und Asterisk immer noch nicht perfekt. Das ist eigentlich der einzige Pferdefuß, was mir bisher aufgefallen ist.
Hat jemand sonst noch dieses Problem? Hat vielleicht jemand mod_gsmopen unter freeswitch angeschaut und funktioniert es dort besser?
 
Auf meinem Alix-Board läuft eigentlich alles perfekt, bis auf ein Problem: Nach einigen Stunden oder Tagen Laufzeit gibt es plötzlich Stille (nur in eine Richtung oder auch in beide). "module unload chan_dongle.so" und dann "module load chan_dongle.so" bringt nichts. Mit einem "core restart now" ist das Problem dann aber beseitigt. So wie ich das sehe, ist das Zusammenspiel zwischen chan_dongle und Asterisk immer noch nicht perfekt. Das ist eigentlich der einzige Pferdefuß, was mir bisher aufgefallen ist.

Also ich verwende Asterisk1.8/chan_dongle mit E1550/E180 auf unterschiedlichen Geräten/Architekturen und habe das Setup auf manchen Hosts Wochen/Monate durchgehend problemlos laufen. Bisher unangenehm aufgefallen ist mir das Problem mit empfangenen SMS, welche gänzlich unleserlich sind sobald sie mehr als 140 Zeichen enthalten und dass kein zweiter Anruf getätigt werden kann wenn einer bereits aktiv ist. (obwohl der Netzanbieter das erlaubt und es auch aktiviert ist) Achja, manchmal hört der Anrufer nur Rauschen wenn gesprochen wird obwohl der Angerufene alles normal hört, bis ich Asterisk neustarte, woran das liegt und wieso das nur manchmal passiert bin ich noch nicht drauf gekommen.

Hat jemand sonst noch dieses Problem? Hat vielleicht jemand mod_gsmopen unter freeswitch angeschaut und funktioniert es dort besser?

Freeswitch schau ich mir seit kurzem auch an, in der Hoffnung dass das "besser" funktioniert, nur hänge ich (noch) an der Konfiguration; den E1550 hab ich schon erfolgreich einbinden, anrufen und dann durchs Freeswitch Demo-Menü navigieren können.
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,118
Beiträge
2,246,397
Mitglieder
373,604
Neuestes Mitglied
thommy_63
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.