[Info] Fritz!Box als GSM-Gateway für Sprachtelefonie über UMTS-Stick (u.a 736x, 7390, 7490)

[Micha0815]

@rabbe, dass in bestimmten Funkzellen -MANY TX @inquisitor für die Erläuterung in http://www.ip-phone-forum.de/showthread.php?t=240840&page=135&p=2084791&viewfull=1#post2084791 an einem stationären=fixen Standort SIMs auf dieselbe Rufnummer bzgl. GSM-Telefonie-Tarifen, man/frau umdenken muss? Der Standort Wiener-Neustadt bietet imho LTE-Netz. Wenn dort fix GSM-Flatrate und hinter einem LTE-Teil schnelle Clients arbeiten möchten, braucht es halt zwei FBs mit entsprechenden Sticks oder neben der wohl vorhandenen FB7390+GSM-Stick halt einen weiteren LTE-Router, der ggfs. I-Net-Clients was schneller anbindet.

OT und ein wenig neidisch schielt wohl so mancher in DE auf die Angebote in AT ... dort haben wirklich wenige Leutz "noch" einen Festnetznetzanschluss. Und der Platzhirsch A1 gibt den Privatleutz KEINE VOIP-Nr. gratis dazu an in ihren reinen ADSL-Anschlüssen... <hüstel> soll vorkommen, dass eine von 10 1&1-Nummern sich in eine AT-FB verirrt nachdem sipgate.at aufgebenen und zudem deren Rufnummern vormals extra-nicht in Freiminutenkontingenten/Flatrates enthalten waren.

LG Micha + Bitte keine REs zu meinem OT ... neuer Thread please an anderer Stelle?

@ NetSupport Das/Dein Problem zieht sich seit Bestehen dieses Threads wie ein roter Faden durch! Die wirkliche Ursache und seine Behebung konnte imho bis dato niemand fixieren! ... Ist imho auch Stickmodell/FB-unabhängig. Ich lasse entfernte FBs täglich nachts einmal neu starten via DECT200. Andere nutzen eine Billig-Schaltuhr? Das wirklich bittere ist, dass wenn Niemand den Stecker lokal/vorort ziehen kann, eine solche FB via VPN nicht erreichbar ist!
LG

 

[erik]

Was diese dauernden Verbindungsverluste angeht: Ich habe drei Sticks (K3565 Rev.2 (H), K3765 (HV) und E173u1) an drei Sorten Fritzbox getestet. Alle drei Sticks liefen stabil an der 7240, der 7360 und der 7390, wobei ich die eventuellen Hardwarerevisionen der Fritzboxen (insbesondere der 7390) nicht überprüft habe. An einer 7270 hingegen lief keiner der drei Sticks dauerhaft stabil. Diese 7270 habe ich aber nicht mehr, ich glaube das war eine v3. Vom Stick scheint das aller Wahrscheinlichkeit nach also nicht abzuhängen. Ich muß aber dazu sagen daß ich immer Vodafone-Karten verwendet habe und bei mir der eher seltene Fall zutrifft daß bei starkem UMTS-Signal nur ein schwaches GSM-Signal vorhanden ist. Die Sticks ziehen allem Anschein nach bei einer GSM-Verbindung mehr Strom als bei einer UMTS-Verbindung, während im Standby der Verbrauch bei GSM wohl geringer sein soll. Der Verlust der Verbindung zur Fritzbox soll ja besonders oft beim Wechsel zwischen den Mobilfunknetzen auftreten, was bei mir ja nicht passiert. Trotzdem war die 7270 nicht zum Betrieb mit dem Stick zu überreden.

 

[baumgaphil]

Ich habe einen E352 mit Firmware 31.116.27.02.00. Diese Version von E352 bietet die Hardware für Voice. Leider ist sie laut DC Locker "disabled".

Ich habe nun mit AT^CVOICE=1 die Telefoniefähigkeit eingeschaltet und konnte sie mit der Mobile Partner Software benutzen - sprich Anrufe haben funktioniert. Nur leider ist es so, dass jedesmal wenn ich den UMTS-Stick abziehe, diese Einstellung wieder verloren geht. Hat jemand eine Ahnung, wie ich die Einstellung "persistent" machen kann?

 

[Micha0815]

Probiere es mal mit Firmware 31.116.27.07.00.B721 (für den E352r-1). Ohne Gewähr auf schädliche Folgen!! U.U. mag die FW 31.116.27.02.00 das Telefonieren nicht . SIM - und Netlockfrei sollte er a priori sein.

LG

 

[unrealzocker]

Ich habe nun mit AT^CVOICE=1 die Telefoniefähigkeit eingeschaltet und konnte sie mit der Mobile Partner Software benutzen - sprich Anrufe haben funktioniert. Nur leider ist es so, dass jedesmal wenn ich den UMTS-Stick abziehe, diese Einstellung wieder verloren geht. Hat jemand eine Ahnung, wie ich die Einstellung "persistent" machen kann?

Du müsstest bei jedem Start/Anschließen des Sticks den Befehl senden.

echo -e "AT^CVOICE=1" > /dev/ttyUSB0

So ungefähr mit Linux.

 

[Micha0815]

Nurmal so

... Alle drei Sticks liefen stabil an der 7240, ... Ich muß aber dazu sagen daß ich immer Vodafone-Karten verwendet habe und bei mir der eher seltene Fall zutrifft daß bei starkem UMTS-Signal nur ein schwaches GSM-Signal vorhanden ist. Die Sticks ziehen allem Anschein nach bei einer GSM-Verbindung mehr Strom als bei einer UMTS-Verbindung, während im Standby der Verbrauch bei GSM wohl geringer sein soll. Der Verlust der Verbindung zur Fritzbox soll ja besonders oft beim Wechsel zwischen den Mobilfunknetzen auftreten, was bei mir ja nicht passiert. Trotzdem war die 7270 nicht zum Betrieb mit dem Stick zu überreden.

Ich kann nunmehr seit Jahrerlanger Erfahrung mit div. Sticks und temporär angeschlossenen FBs bestätigen, dass die FB7240 irgendwie bei mir am stabilsten läuft. Eine 7340 hat sich im ES-VDF-Netz auch als reines GSM-Gateway recht wacker geschlagen (rd.2,5 Monate bevor sie an einen DECT200 gepackt wurde ) Zu Beachten imho, ob über einen Stick ambivalent gearbeitet wird -sprich GSM + UMTS-I-Net oder reines GSM-Gateway.

Wer wie ich auf VPN-Zugriff aus der Ferne angewiesen ist empfehle ich trotzalledem via Zeitschaltuhr oder in meinem Fall mittlerweile 2 Dect200, die sich kreuzweise steuern und per LAN intern verbunden sind (- an Dect200-1 hängt eine FB7340 und wird von FB 7240 gesteuert, und an DECT200-2 hängt die I-Net-FB7240 und wird von der FB7340 gesteuert ... zeitversetzt nach nächtlicher Push-Mail schalten die DECT200 für 1 Minute die jeweilige andere Box mal kurz aus!), die Boxen regelmässig neu zu starten.

LG

Nachtrag für Erik: Die Anhänge zeigen die aktuellen Meldungen der DECT200 -die Messen imho recht genau abgesehen vom Eigenverbrauch?- zum Stromverbrauch der beiden Boxen jeweils mit einem K3756 HV. Rein rechnerisch, wenn an einem USB-Anschluss direkt ein Stick hängt mit 5Volt mit/mal max. 500mA ... wären das 2,5 Watt von rd. 8Watt? Dies erscheint mir nicht übermässig? ... allein die Vergleichsmöglichkeit mangels DSL-FB-Box hinter/an einem DECT200 fehlt mir! ... an der FB7340 (am 2ten USB-Anschluss hängt noch ein Speicherstick für AB+FAX-Empfang)

 

[baumgaphil]

Auch neuere Firmware zeigt gleiches Verhalten

[...]

Vielen Dank für den Hinweis. Ich habe die Wind/It-Version der neueren Firmware geladen. Leider genau dasselbe verhalten. Hat jemand eine Version, bei der Voice geht?

 

[Shrinker]

Habe mir nun auch Huawei K3765 als GSM-Gateway an meiner 7490 eingerichtet. Funktioniert soweit einwandfrei, nur die Lautstärke auf der Fritzseite ist etwas schwach. Gibt es da eine einfache Lösung?

Nun zum eigentlichen Problem:
Ich verwende Multisim von O2, eine im Handy und eine im K3765 an der Fritz. Der Anrufempfang wird mit dem Code *123# auf dem jeweiligen Gerät eingestellt.

Wie kann ich den Code z.B. übers DECT-Telefon zum K3765 senden?

 

[thtomate12]

Das ist USSD, das kann die Box nicht, da das ein anderer AT-Befehl als für normale Anrufe ist

 

[Shrinker]

Danke für die schnelle Antwort. Das ist natürlich Mist. Gibt es vllt. iirgendeinen Trick oder Kniff wie ich die Gespräche zur Box zurück schalten kann? Parallelsignalisierung gibt es bei O2 nicht und über die Hompage von O2 dauert es manchmal bis zu einer Stunde bis die Umschaltung greift.

 

[KiRKman]

Ich glaube, bei Nutzung der MultiCards von o2 sind die *120# Codes schon sehr notwendig. Und genau die kannst Du leider nur von Deinem Standard-Phone aus senden, nicht jedoch von der FRITZ!Box.

Also entweder kannst Du da "extern" vom Handy bzw. Smartphone aus was ändern, oder Du musst es so einstellen, dass immer die zuletzt eingebuchte Karte die Anrufe empfängt. In diesem Fall könntest Du dann den Stick von der Box ziehen und neu anstecken, um die Karte im Stick frisch einzubuchen. Somit würden die Anrufe dort landen, bis Du das Handy wieder einbuchst.

Das ist jedoch alles umständlich. Die Aktualisierung über die o2-Seite ist anscheinend aber auch keine Lösung...

 

[andiling]

Du kannst ja Prioritäten einstellen, z.B.

- Empfang auf Fritzbox wenn Smartphone aus
- Empfang auf Smartphone wenn FB SIM offline

 

[PeterPawn]

Auch USSD-Codes lassen sich - bei einigen Sticks zumindest - über AT-Kommandos senden (AT+CUSD). Wie so ein Kommando aufgebaut ist und wie man ermitteln kann, ob der eigene Stick es unterstützt, steht in irgendeiner der hier veröffentlichten Spezifikationen ... für AT+CUSD kann ich im Moment aber nicht sagen, in welcher.

Jedoch muß dazu der umtsd und der csvd (in der Folge event. auch der voipd) vorübergehend gestoppt werden, damit man auf den seriellen Port zugreifen kann.

Bei Ethernet-Emulation gibt es u.U. eine "Seite" in der "Oberfläche" des Sticks, wo man USSD-Codes senden kann, da ginge das zur Not auch parallel, aber mit solchen Sticks kann dann der csvd im Moment ja ohnehin nichts anfangen und der K3765 gehört m.E. auch nicht dazu.

Nachdem man dann die USSD-Befehle abgesetzt hat, kann man die AVM-Daemons wieder starten, die richtige Reihenfolge findet sich in den AVM-init-Files.

Das ist also durchaus zu realisieren ... aber nicht mit der originalen Firmware ohne jede Änderung. Man bräuchte zumindest so etwas wie eine eigene Webseite in der Box (das kann auch ein Busybox-httpd sein), über die man dann das Senden solcher AT-Kommandos anstößt. Da entsteht dann auch wieder die Frage, wie man solche eigenen Erweiterungen startet ... auch wenn es dafür Lösungen gibt.

Ob das tatsächlich auch über Telefontasten-Codes machbar ist, müßte man testen. Es gab mal die Möglichkeit, in Kombination mit FHEM (als AVM es noch unterstützte) mit #95*[n]* auch Kommandos an das "fhemcmd"-Skript zu übermitteln. Ob das von AVM im Zuge des Wegfalls der FHEM-Unterstützung ausgebaut wurde oder noch als "Blinddarm" in der Firmware (in 'telefon') enthalten ist, weiß ich derzeit nicht.

 

[Shrinker]

Ich denke mal alles zu Umständlich bzw. kompliziert. Scheint nur der Ansatz von andiling eine Möglichkeit zu sein.
Sehe aber auch da keine Lösung. Auf eine Lösung von AVM brauche ich wohl kaum zu hoffen.

 

[ciesla]

AVM macht da definitiv nichts. Haben sie schon früher bestätigt. Lohnt sich in Zeiten von Allnet-Flats nicht.

 

[inquisitor]

Wie man USSD-Befehle versendet, steht im ersten Post dieses Threads. Leider bekommt man auf die entsprechenden Befehle keine Antwort, womöglich werden sie aber trotzdem ans Netz übermittelt. Rückmeldungen sind erwünscht!

 

[PeterPawn]

Wie man USSD-Befehle versendet, steht im ersten Post dieses Threads.

Ich gehe mal mit schlechtem Beispiel voran und "oute" mich, dass ich zu den Leuten gehöre, die nicht alle >2700 Beiträge hier gelesen haben. Vielleicht wäre es ja an der Zeit, das etwas kondensierter anzubieten? Auch wenn es natürlich nicht in Ordnung ist, sogar den ersten Beitrag in einem Thread zu ignorieren ... ich wollte mich dabei definitiv nicht "mit fremden Federn schmücken". Sorry.

Wobei ich auch nicht ganz sicher bin, ob es tatsächlich bei jedem Stick korrekt ist, diese Kommandos an den DATA-Port zu senden (zumindest die Kolllision mit dem umtsd ist da wohl vorprogrammiert) ... ich teste das zwar irgendwann in den nächsten 48 Stunden noch einmal, aber ich würde den CONTROL-Port (/var/gsm/ttyCONTROL) für "logischer" halten, da solche Codes ja auch bei aufgebauter Verbindung (und damit "Datenmodus" auf dem DATA-Port, den man erst durch geeignete Escapes wieder verlassen müßte) gesendet werden können. Da das aber meines Wissens in der Spezifikation gar nicht festgelegt ist, welche Kommandos auf welchem Port zu verarbeiten sind, wenn das TE mehrere Schnittstellen zur Verfügung stellt, ist das wohl nur durch eigenes Probieren zu erkunden.

Dabei kann dann (wenn man eine eigene Busybox auf einem USB-Stick zur Verfügung hat) auch auf das Applet "microcom" zurückgreifen, das erspart einem den Umgang mit zwei getrennten Sitzungen zur Anzeige von Ausgaben und zum Senden der Kommandos (Beenden mit Ctrl-X). Wenn ich das Programm bei aktiver Mobilfunk-Datenverbindung auf den CONTROL-Port eines MF190V mit "AT+CUSD=?" loslasse, kriege ich dort jedenfalls erst mal die Antworten und auch so ziemlich jedes andere AT-Kommando wird dort ausgeführt. Ob die Antworten seitens des TA da auch ausgegeben werden bei "echten" AT+CUSD-Kommandos (wo die Antwort ja eigentlich aus dem Netz kommt und wohl eher "unsolicited" ist), weiß ich aber auch noch nicht ... zumindest "intermediate result codes" (also das "OK" oder auch ein "ERROR") kommen auf dem CONTROL-Port heraus.

Da die FRITZ!Box damit dann eigentlich noch nichts so richtig zu tun hat (außer sie hat den Stick in irgendeinen komischen Modus geschaltet), werde ich das mal - bei Gelegenheit - auch auf anderen Ports testen. Es ist für mich nur nicht so simpel, einen funktionierenden USSD-Code zu finden, der auch eine entsprechende Ausgabe produziert, wenn es nicht gerade eine Prepaid-Karte mit der Möglichkeit zur Guthabenabfrage ist. Hat jemand einen getesteten Vorschlag für einen USSD-Code mit netzseitiger Antwort für eine Telekom-Postpaid-SIM (keine Multi-SIM, da funktioniert die Umschaltung des SMS-Empfangs dann wieder)?

Um #2714 dann noch um die fehlende Quellenangabe zu ergänzen ... AT+CUSD ist Section 7 (hier) auf Seite 60 beschrieben.

 

[KiRKman]

Vielleicht mal mit *135# probieren - Abfrage der eigenen Mobilfunknummer (MSISDN).

 

[Shrinker]

Habe die folgenden Code mal für die Umschaltung getestet.

echo -e "AT+CUSD=1,*123#,15\r" > /var/gsm/ttyDATA
echo -e 'AT+CUSD=1,"*123#",15\r' > /var/gsm/ttyDATA
echo -e "AT+CUSD=1,\"*123#\",15\r" > /var/gsm/ttyDATA

wurden auch in der anderen Console mit ok quittiert und haben auch umgeschalten. Die anderen beiden hatten keine Wirkung.
Jetzt gehts nicht mehr, trotz Boxneustart usw. Jetzt kommt in der 1. Console immer nur: +CME ERROR: no network service

 

[PeterPawn]

Jetzt gehts nicht mehr, trotz Boxneustart usw. Jetzt kommt in der 1. Console immer nur: +CME ERROR: no network service

Stick abziehen (stromlos) und wieder anstecken könnte helfen.

Bei Huawei-Sticks ging mal das Gerücht um, daß die das Format "15" für USSD nicht verstehen würden und stattdessen mit GSM-7Bit-Codes oder IRA "gefüttert" werden wollen. Das wäre für "*123#" dann die GSM7-Kodierung "AA986C3602". Theoretisch müßte dann das DCS (das "data coding scheme") auf 0 oder 1 gesetzt werden, wenn sich Huawei an den Standard hält (2 oder 3 ging event. auch noch).

Die erste von Dir probierte Form des AT-Befehls sollte eigentlich einen Fehler liefern, denn die Spezifikation sieht das ausdrücklich als "string type USSD-string" vor (siehe das Beispiel auf Seite 14 für "string type") und da sollten eigentlich die Anführungszeichen in jedem Falle erforderlich sein.

Was also vielleicht einen Versuch wert ist, wäre das Kommando

AT+CUSD=1,"AA986C3602",1

an den Stick zu senden. Wenn das unbedingt an den DATA-Port sein soll, dann eben dort hin, solange Du keine Datenverbindung aktiv hast. Für ein "echo"-Kommando wäre jedenfalls die zweite von Dir probierte Form dann die richtige (drei funktioniert sicherlich auch, während eins eigentlich ungültig ist), das einfachste ist es allerdings, dieses Kommando in einer Datei abzuspeichern und diese mit "cat" an den Port auszugeben (dabei auf CR/LF achten, das ist im Standard so definiert -> was das TA macht, wenn da nur LF kommt, ist nicht einheitlich).