[Diskussion]: UMTS-Stick an der FBF als GSM-Gateaway verwenden.

[PsychoMantis]

Ich habe nun E1550 statt K3520 genommen: nun wird er von der FBF auch als usb2.0-Gerät erkannt. Aber das löst das Problem nicht: Die Qualität ist in die eine Richtung besser als in die andere. Ich denke, dass zuerst dieses Problem gelöst werden sollte, bevor man an der Dauerstabilität arbeitet.
Im Energiemonitor der FBF sieht man die CPU-Last. Beim Anruf geht die CPU auf 78%. Ich würde gerne die CPU testweise auf 100 % bringen, doch wie?
@ waldoo: Beendest du den umtsd nicht? Geht es bei dir mit laufendem umtsd? Was kannst zur Qualität genauer sagen? Ich meine wenn du jemanden anrufst, wirst du ja normalerweise schlechter verstanden während du selbst den Gesprächspartner bestens hörst (so ist es bei mir). Ist es dir irgendwie gelungen den umts-Stick zum telefonieren zu nutzen und gleichzeitig als SD-Cardreader?

Ich habe unser Problem im russischen Forum zu Wort gebracht. Die leute dort wissen nicht was eine Fritzbox ist.
Der chan_dongle-Entwickler meinte jedoch allgemein (frei übersetzt):

Bezüglich voice in eine Richtung:
man muss schauen was es für eine architektur ist, auf big-endian fand man mal paar Probleme mit der Qualität

Und auf alle Fälle sollte man ins asterisk schauen ob da ein timing module vorhanden ist und welcher.

UMTS-Stick sollte man in einen aktiven Hub rein stecken, sonst schafft das Netzteil die Belastung nicht...
Und der Prozessor (CPU) könnte zu schwach sein, wenn 200 MHz

Nachtrag: Ich habe jetzt asterisk nochmal kompiliert zusätzlich mit res_timing_pthread.so
Damit ist die Qualität anders geworden, aber nicht unbedingt besser. Vielleicht ist es das falsche Timing-Modul? Zumindest liest sich das so. Auf meinen Vserver-Asterisk habe ich gesehen, dass dort res_timing_timerfd.so verwendet wird. Ich teste es mal damit...

Ich lasse von meinem Vserver über chan_dongle (auf der FBF) mich auf dem Handy anrufen und irgendwas vorspielen: Die Qualität ist ohne irgendwelche Timing-Module bestens. Ruft mich jedoch irgendjemand vom vserver aus an (auch über chan_dongle auf der FBF) verstehe ich den jenigen eigentlich, aber die Qualität ist nicht top. Der Gesprächspartner hört mich dagegen bestens. Warum gibt es in diesen beiden Fällen Qualitätsunterschiede, obwohl das Audio doch jedesmal vom vserver über chan_dongle zum Handy geht???

Ich habe mich aber natürlich schon gefragt, warum es ohne Timing Module besser funktioniert als mit, obwohl bg1 doch zugesichert hat, dass es genau andersrum sein müsste. Die Antwort liegt in diesem Vergleich zwischen Vserver-Asteisk und Asterisn_on_FBF:

vserver*CLI> timing test 1000
Attempting to test a timer with 1000 ticks per second.
Using the 'timerfd' timing module for this test.
It has been 1000 milliseconds, and we got 1000 timer ticks
vserver*CLI>
___________________________________________________________

fritz*CLI> timing test 1000
Attempting to test a timer with 1000 ticks per second.
Using the 'timerfd' timing module for this test.
It has been 1003 milliseconds, and we got 241 timer ticks
fritz*CLI>

Man müsste also irgendwie das timing-Modul richtig einstellen, dies scheint im Kernel jedoch nicht drin zu sein. Das kann also wohl nur ein Experte machen (es gibt ja im freetz die Möglichkeit eigenen Linux-Kernel für die FBF zu kompilieren).
Nachtrag: Ohne Timing-Modul ist die Qualität (in die eine Richtung) unbrauchbar!

 

[waldoo]

fritz*CLI> timing test 1000
Attempting to test a timer with 1000 ticks per second.
Using the 'pthread' timing module for this test.
poll() timed out!  This is bad.
poll() timed out!  This is bad.
poll() timed out!  This is bad.
poll() timed out!  This is bad.
poll() timed out!  This is bad.
poll() timed out!  This is bad.
poll() timed out!  This is bad.
poll() timed out!  This is bad.
poll() timed out!  This is bad.
poll() timed out!  This is bad.
It has been 1016 milliseconds, and we got 0 timer ticks
[Aug 19 22:20:45] ERROR[12822]: res_timing_pthread.c:163 pthread_timer_set_rate: res_timing_pthread only supports timers at a max rate of 100 / sec
fritz*CLI> timing test 100
Attempting to test a timer with 100 ticks per second.
Using the 'pthread' timing module for this test.
It has been 1004 milliseconds, and we got 100 timer ticks
fritz*CLI> core show version
Asterisk 1.6.2.20 built by freetz @ debian_asterisk on a x86_64 running Linux on 2011-08-10 21:36:58 UTC
fritz*CLI>

Bei mir schaut das ein wenig anders aus. Habe nur das eine timing modul am laufen und das lese ich sollte auch das richtige sein
https://reviewboard.asterisk.org/r/164/diff/2/

Beim Anruf geht die CPU auf 78%

Sieht das an der Konsole genauso aus? Bei mir bleibt alles im normalen rahmen.

Anbei mal alle Module, die ich am laufen habe.

root@fritz:/var/media/ftp/USBstick_ext/addons/asterisk16/usr/lib/asterisk/modules# ls
app_adsiprog.so             app_minivm.so               app_userevent.so            codec_a_mu.so               func_callerid.so            func_uri.so
app_alarmreceiver.so        app_mixmonitor.so           app_verbose.so              codec_adpcm.so              func_cdr.so                 func_version.so
app_amd.so                  app_morsecode.so            app_voicemail.so            codec_alaw.so               func_channel.so             func_vmcount.so
app_authenticate.so         app_mp3.so                  app_waitforring.so          codec_g722.so               func_config.so              func_volume.so
app_cdr.so                  app_nbscat.so               app_waitforsilence.so       codec_g726.so               func_curl.so                pbx_ael.so
app_chanisavail.so          app_originate.so            app_waituntil.so            codec_gsm.so                func_cut.so                 pbx_config.so
app_channelredirect.so      app_parkandannounce.so      app_while.so                codec_lpc10.so              func_db.so                  pbx_dundi.so
app_chanspy.so              app_playback.so             app_zapateller.so           codec_ulaw.so               func_devstate.so            pbx_loopback.so
app_confbridge.so           app_playtones.so            bridge_builtin_features.so  format_g723.so              func_dialgroup.so           pbx_realtime.so
app_controlplayback.so      app_privacy.so              bridge_multiplexed.so       format_g726.so              func_dialplan.so            pbx_spool.so
app_db.so                   app_queue.so                bridge_simple.so            format_g729.so              func_enum.so                res_adsi.so
app_dial.so                 app_read.so                 bridge_softmix.so           format_gsm.so               func_env.so                 res_ael_share.so
app_dictate.so              app_readexten.so            cdr_csv.so                  format_h263.so              func_extstate.so            res_agi.so
app_directed_pickup.so      app_readfile.so             cdr_custom.so               format_h264.so              func_global.so              res_clialiases.so
app_directory.so            app_record.so               cdr_manager.so              format_ilbc.so              func_groupcount.so          res_clioriginate.so
app_disa.so                 app_sayunixtime.so          cdr_sqlite3_custom.so       format_jpeg.so              func_lock.so                res_config_curl.so
app_dumpchan.so             app_senddtmf.so             chan_agent.so               format_pcm.so               func_logic.so               res_convert.so
app_echo.so                 app_sendtext.so             chan_bridge.so              format_siren14.so           func_math.so                res_crypto.so
app_exec.so                 app_setcallerid.so          chan_capi.so                format_siren7.so            func_md5.so                 res_curl.so
app_externalivr.so          app_sms.so                  chan_dongle.so              format_sln.so               func_module.so              res_limit.so
app_festival.so             app_softhangup.so           chan_dongle.so_old_working  format_sln16.so             func_rand.so                res_monitor.so
app_followme.so             app_speech_utils.so         chan_iax2.so                format_vox.so               func_realtime.so            res_musiconhold.so
app_forkcdr.so              app_stack.so                chan_local.so               format_wav.so               func_sha1.so                res_phoneprov.so
app_getcpeid.so             app_system.so               chan_mgcp.so                format_wav_gsm.so           func_shell.so               res_realtime.so
app_ices.so                 app_talkdetect.so           chan_phone.so               func_aes.so                 func_sprintf.so             res_smdi.so
app_image.so                app_test.so                 chan_sip.so                 func_audiohookinherit.so    func_strings.so             res_speech.so
app_macro.so                app_transfer.so             chan_skinny.so              func_base64.so              func_sysinfo.so             res_timing_pthread.so
app_milliwatt.so            app_url.so                  chan_unistim.so             func_blacklist.so           func_timeout.so

Hab mir schon mal überlegt, ob ich einen Wireshark trace von meinem Telefonat mache, dann könnten wir das mal vergleichen, ob das mit Deiner Qualität gross abweicht.
Ich frage nämlich nicht bei jedem Telefonat nach, ob ich genauso gut wie sonst auch verstanden wurde.

Auf der chan_dongle Projektseite habe ich schon gesehen, dass über big-endian und Sprachqalität geschrieben wird.

 

[PsychoMantis]

Wie man die CPU-Leistung in der Konsole nachschauen kann - weiß ich nicht. Das mit der CPU scheint aber irgendwie nicht die Lösung zu sein.
Ich hatte auch keine Lust jedesmal zu fragen, ob mich mein Gegenüber gut versteht.
Normalerweise ist es ja so, dass man über das so gebastelte GSM-Gateway jemanden anruft. Unser Qualitätsproblem ist aber immer auf der anderen Seite: also der jenige, den wir anrufen hört mich schlecht. Daher habe ich das anders rum gemacht: Ich lasse mich über das GSM-Gateway anrufen, so dass ich der jenige bin, der alles schlecht versteht. Ich muss sagen, dass die Qualität nicht wirklich berauschend ist.
Der pthread-timer ist zwar ein timer, aber laut chan_dongle Entwickler sollte vorzugsweise timerfd verwendet werden.
Die Module, die du hast, sind genau die, die ich auch verwende, bis auf die Tatsache, dass ich noch res_timing_timerfd.so drin habe (dann verwendet Asterisk automatisch ihn und nicht pthread).
Wireshark wird nicht viel nutzen, denke ich, da die Qualität ja erst nach chan_dongle schlecht wird (du kannst es also nur selbst hören, wenn du der angerufene bist).
Meine Vermutung ist also, dass der timer im Kernel nicht mit einkompiliert ist. Idee zum Test: Man kann doch (oder?) selbstkompiliertes Debian auf der FBF laufen lassen. Vielleicht sollte man testen, ob die FBF unter Debian bessere Qualität liefern würde.
Ach ja, bzgl. diesem big und little Endian: Auf meiner 7270er war das mit der Qualität genau das gleiche: das Problem liegt also wohl nicht daran, dass die 7390er eine big-endian CPU hat.
Ich habe überlegt, überlegt, überlegt...so wie es aussieht, bräuchte man einen timerfd für Asterisk. Diesen müsste man aber optimal für die FBF kompilieren. Wer hat das nötige Verständnis um dies zu tun?

So Leute. Wir haben es zwar nicht ganz hinbekommen, aber AVM anscheinend schon. Zumindest soll es mit der vor paar Tagen erschienenen Labor für die 7390er gehen. Zum Test geht und Diskussion darüber geht es hier lang.

 

[langust]

Asrerisk Binaries für FB 7320 (AR9)?

Hallo zusammen,

habe vor Kurzem FB 7320 von 1&1 bekommen.

Leider hat die Box AR9 und ist wohl mit dem hier von PsychoMantis angebotenen bereits kompilierten Asterisk nicht kompatibel.

Auch Asterisk aus dem anderen Thread (http://www.ip-phone-forum.de/showthread.php?t=217453) ist für ne andere Plattform kompiliert.

Hat das jemand für FB 7320 bereits gemacht?

Es wäre nett, wenn er die Binaries hier hochladen könnte.

Habe leider keine Zeit und wenig Erfahrung das selber zu kompilieren.
Auf unserem Testrechner mit SuSe fehlen leider viele Pakete wie autoconf, automake, g++ u.a.

Danke im Voraus

Gruß
languste

 

[PsychoMantis]

Für die 7390er und 7270er ist eine Labor erschienen, mit der das Telefonieren über den UMTS-Stick geht (also ohne Asterisk und ohne irgendwas zu modifizieren). Ich denke, es wird nicht lange dauern, bis auch die 7320er und 7240er das unterstützt. Warten wir es lieber ab.
Ich könnte ja chan_dongle für deine 7320er basteln, aber da fehlt mir erstens die Zeit und zweitens war die Qualität ja eh nie ganz zufriedenstellend.
Warten wir lieber auf AVM - mit der Labor ist die Qualität auf meiner 7390er ganz in Ordnung.

 

[langust]

Danke für die Info,

ich hoffe, dass AVM uns nicht zu lange warten lässt.

Gruß
languste

 

[HHI]

Woher stammt diese Info? Ich habe auf den AVM-Seiten im Laborbereich nichts dazu finden können...

 

[informerex]

Board-Suche - Fritz!Box als GSM-Gateway über UMTS-Stick (derzeit nur mit 7270 & 7390 Labor)

 

[waldoo]

Ich hab die Laborversion auf meiner 7270V2 ausprobiert.
Hatte bis jetzt mit der regulären 54.05.05 ja nichts gross machen müssen. Chan_dongle hat die UMTS Karte erkannt und ich konnte über sie Telefonieren. War ja im AVM Webinterface alles mit UMTS deaktivert.

Mit der Labor ist es allerdings so, dass das /dev/ttyUSB1 und /dev/ttyUSB2 immer geblockt wird und chan_dongle das device nicht mehr ansprechen kann.
Wenn ich aber den "umtsd" Prozess von AVM stoppe, dann würde es prinzipiell von chan_dongle angesprochen werden können,aber ich hatte dann bei meinen Tests nur einseitigen Ton.
Auch hier bin ich ja eigentlich davon ausgegangen, dass wenn im AVM Webinterface die Funktion "Telefonie über UMTS Verwenden" nicht gesetzt ist, das Device freigehalten wird.
Dem ist aber wie beschrieben aktuell nicht so.
Ein Ticket gegenüber AVM-Labor hat leider nichts gebracht.

 

[baeckerman83]

Bedeutet das, wenn man die Laborfirmware installiert kann man den UMTS Stick nicht mehr nutzen? Also man brauch dann immer die chan_dongle?

 

[PsychoMantis]

Nein, das bedeutet wenn man die Laborfirmware installiert, dann kann man den UMTS-Stick für Internet nutzen. Aber chan_dongle kann man dann nicht nutzen.
Allerdings braucht man mit der Labor in den meisten Fällen dann kein chan_dongle mehr, da es ja nun von AVM (im Betastadium!) unterstützt wird den UMTS-Stick als GSM-Gateway zu benutzen.

Wenn AVM in die Firmware noch das Verschicken und Empfangen von USSD und SMS einbaut und die Möglichkeit lässt mehrere UMTS-Sticks über einen USB-Hub zu nutzen, dann wird man in der FBF gar kein chan_dongle mehr brauchen.

 

[baeckerman83]

Ich wollte den Stick auch nur zum raustelefonieren benutzen. SMS verschicke ich über eine HTTP Schnittstelle. Die FB wäre bei mir nur für Voice Zuständig. Internet macht mein SpeedportW920V.

 

[PsychoMantis]

Naja. Installier die Labor - dann brauchst du kein chan_dongle mehr.
Allerdings ist das noch in der Experimentierphase. Anderseits ist die Gesprächsqualität mit der Labor besser also vorher mit chan_dongle.

 

[baeckerman83]

Naja. Installier die Labor - dann brauchst du kein chan_dongle mehr.
Allerdings ist das noch in der Experimentierphase. Anderseits ist die Gesprächsqualität mit der Labor besser also vorher mit chan_dongle.

Oki danke dann weiß ich bescheid. Hatte net so ganz verstanden ob das mit der Laborfirmware geht.

 

[voip-charly]

Hallo,
Frage 1: Wie richte ich denn in der 7390 die Rufumleitung auf den UMTS-Stick ein? Im Assistenten des Rufumleitungsmenüs wird die Rufnummer in der Auswahlbox nicht angezeigt obwohl sie im Menü als eigene Rufnummer in der Box vorhanden ist! *13# kann an der Stelle im Assistenten auch nicht eingetragen, da dort eine Rufnummer erwartet wird.

Frage 2: Ich brauche eine Wahlregel Mobilfunk die besagt, dass alle Handynummern über beispielsweise Easybell rausgehen, ausser eine Mobilfunknummer die über den Stick (GPRS Gateway) gehen soll. Das heißt ich möchte nicht manuelle alle Mobilfunknummern nur wegen der einen Rufnummer getrennt auflisten (0151 0160 0170 ... etc.)

 

[Fox.Mulder]

Zu Frage 2: I.d.R. haben individuelle Rufnummern Vorrang vor allgemeinen Festlegungen, d.h. wenn man die allgemeine Regel Mobilfunk definiert, kann man trotzdem noch individuelle Nummern über einen anderen Weg definieren.

 

[baeckerman83]

Ich habe den Befehl "datacard show devices" bei meiner Asterisk 1.6 installation nicht. Woran könnte das liegen? Fehlt mir ein Modul? Bei Freetz hatte ich datacard mit ausgewählt.

 

[waldoo]

dann ist das modul "chan_datacard.so" nicht geladen. ist das bei Dir vorhanden?
Wenn du den letzen Patch vom Ticket #706 von freetz.org genommen hast, dann ist "chan_datacard" nicht mehr enthalten, da es nicht mehr weiterentwickelt wird.
Der Nachfolger ist nun "chan_dongle" und sollte das gleiche machen (dongle show devices)

 

[baeckerman83]

Danke das hat geholfen.

 

[waldoo]

Hi zusammen,
habe eine Info zu USB 1.1 mit dem Datenstick gefunden. Das dürfte dann die Boxen wie 7170 betreffen:
https://groups.google.com/forum/?fromgroups#!topic/chan_dongle/w2ZAJMMTvW4

So,
as results
Usage of USB 1.1 may get one way sound, from GSM to asterisk OK, but
from asterisk to GSM party silence.

Hatte bei kurzen Tests mit der 7170 eigentlich die gleichen Erfahrung gemacht.
Wollte das ganze nur über vpn realisieren. Den "one-way-sound" hatte ich dann auf das setup geschoben...