Fritz!Box 6490 Kabeldeutschland VOIP

Keine Ahnung, wie daniello das geschafft hat, aber im Editor wird definitiv ein falscher Zeichensatz verwendet.
Sehr warscheinlich führt die Eingabe von "normalen" Buchstaben über die Tastatur auch zur Darstellung solcher "Sonderzeichen".
Joe

Ich hab nüscht jemacht .. schwöre ;-)

Wenn ich in das Fenster tippel kommt auch nur Unsinn raus. Die Felder (z.B. zum IP eingeben) sind ok.
 
Keine Ahnung, wie daniello das geschafft hat, aber im Editor wird definitiv ein falscher Zeichensatz verwendet.
Ja, sehe ich genauso ... deshalb auch - jenseits seines eigentlichen Problems - der Versuch, die Ursache zu ermitteln, damit man beim nächsten Fragesteller mit einem ähnlichen Problem nicht erneut raten muß. Wenn es sich auf den FBEditor und eine dort getroffene falsche Einstellung beschränken sollte (ich wüßte aber auch nicht, wie die dort hin kommen sollte), dann müßte das Löschen der properties.xml reichen. Ich finde in einer V7-Standard-Runtime keine Einstellung, die die Anzeige erklären würde ... daher tippe ich auf eine neuere Version. Keine Ahnung, ob Oracle da dann auf UTF-16 oder etwas ähnliches umgestellt hat, aber dann dürften die Einrückungen auch nicht mehr so deutlich sein (denn i.d.R. wäre UTF-16-Blank != UTF-8-Blank). Auch die eindeutige Zuordnung (Sterne als "ij", geschweifte Klammer auf als "diamonds") deutet imho nur auf eine falsche Codepage hin. Da das eine systemweite Einstellung sein müßte, tippe ich eben auf eine höhere Java-Version.
 
Ja, sehe ich genauso ... deshalb auch - jenseits seines eigentlichen Problems - der Versuch, die Ursache zu ermitteln, damit man beim nächsten Fragesteller mit einem ähnlichen Problem nicht erneut raten muß. Wenn es sich auf den FBEditor und eine dort getroffene falsche Einstellung beschränken sollte (ich wüßte aber auch nicht, wie die dort hin kommen sollte), dann müßte das Löschen der properties.xml reichen. Ich finde in einer V7-Standard-Runtime keine Einstellung, die die Anzeige erklären würde ... daher tippe ich auf eine neuere Version. Keine Ahnung, ob Oracle da dann auf UTF-16 oder etwas ähnliches umgestellt hat, aber dann dürften die Einrückungen auch nicht mehr so deutlich sein (denn i.d.R. wäre UTF-16-Blank != UTF-8-Blank). Auch die eindeutige Zuordnung (Sterne als "ij", geschweifte Klammer auf als "diamonds") deutet imho nur auf eine falsche Codepage hin. Da das eine systemweite Einstellung sein müßte, tippe ich eben auf eine höhere Java-Version.

XML löschen reicht nicht .. es ist von Anfang an so .. als die zwei Zeilen vorm download sind schon unlesbar. ABER .. mit der 0.7 geht alles .. da ist alles lesbar .. nur mit der 0.7.2 hab ich das Problem.
 
Java Version ist > 8 .. soviel weiß ich.
Nimm 7 und es müßte klappen.

Das Auslesen und Einspielen mit dem FBEditor klappt .. ich editiere und lade hoch. Die Anzeige ist wie gesagt immer kryptisch .. kann ich aber mit leben.
Das heißt dann nach meiner Interpretation, der Editor berechnet die richtige Prüfsumme und deshalb klappt es.

Zu lang zum Erklären, kannst Du selbst nachlesen, gibt diverse Stellen um IPPF und im Internet allgemein.

Aber wie find ich denn die Support-Daten?
Expertenansicht, unten Inhalt, unten FRITZ!Box Support, oben "Support-Daten erstellen", dann Textdatei als Download (im normalen Editor sicherlich auch lesbar ;) EDIT: jedenfalls in einem, der mit Linux-Lines umgehen kann - z.B. Notepad++ als Freeware)

Nur wie ersetze ich die verschlüsselten Credentials .. einfach durch meine echten im Klartext .. sodass die Box dann verschlüsselt?
Exakt so, siehe #16 Absatz 4.

EDIT: Mit FBEditor 0.7 kannst Du vielleicht alles lesen, aber die Prüfsummenberechnung funktioniert nicht. Nimm Java 7 und 0.7.2 beim FBEditor.
 
Zuletzt bearbeitet:
Supportdaten sind prima lesbar .. überwältigen aber den ungeübten Betracher. Danke für den "Weg".

Sorry .. dass ich den Hinweis zu den Klartextpasswötern überlesen hatte .. für die Info war ich da wohl noch nicht bereit.

FBEditor ist mir insgesamt etwas suspekt. Es scheint absoluter Zufall zu sein, dass ich einen Upload hinbekomme der mit der Bestätigung endet, dass die Box nun neu gestartet wird. Mir ist unklar was da abgeht .. ich probiere weiter. Demnach konnte ich auch noch nicht testen ob das mit dem Klartext funktioinert.

Edit: Soll ich Nochecks lieber anhaken?

Edit: Hochladen hat jetzt funktionert .. scheint als würde FBEdit es gut finden, wenn ich erstmal was runterlade bevor ich die gespeicherte Datei öffne und wieder hochlade. Aber leider bin ich noch nicht weiter .. nichts grün .. und besetzt
 
Zuletzt bearbeitet:
Supportdaten sind prima lesbar .. überwältigen aber den ungeübten Betracher. Danke für den "Weg".
Sollte nicht so schwer sein, mit den Buzzwords "VoIP" und "SIP" da die richtigen Informationen zu finden.

Edit: Soll ich Nochecks lieber anhaken?
Eher nicht ... sollte nach 06.05 ohnehin nichts mehr bringen bzw. hat auf Cable-Boxen noch nie etwas bewirkt, außer Import-Fehlern.

Welche Firmware hast Du eigentlich ? Die 06.08 tendierte nach meinen Informationen gerne mal dazu, beim Import über das GUI abzustürzen ... aktuell wäre bei KDG die 06.10.
 
6.10 ist drauf. Muss jetzt nochmal mit dem kompletten Profil probieren (hab nochmal nur die ersten Zeilen getauscht)
 
Muss jetzt nochmal mit dem kompletten Profil probieren (hab nochmal nur die ersten Zeilen getauscht)
1. Wenn es nur noch um fröhliches Probieren geht, bin ich wieder raus.
2. Wenn Du vielleicht einfach mal die übernommenen Angaben mit den Schlüsselwörtern für die Einstellungen beschreiben könntest (es verlangt ja niemand, daß Du die Klartextdaten hier reinstellst) ? Woher sollen wir denn nun wieder wissen, was Du unter "den ersten Zeilen" verstehst bzw. in welcher Reihenfolge das bei Dir in der Datei steht ?

Ich kann mich langsam des Eindrucks nicht mehr erwehren, daß Du "schwimmst" und nicht mehr weißt, was Du da eigentlich genau machst ... das kann auch klappen, aber eindeutig dann nicht mehr mein Tisch.

Und daß Deine Leser hier alle nicht hellsehen können und Du schon genau beschreiben mußt, was Du machst, was das Ergebnis ist und warum das Deiner Meinung nach so nicht in Ordnung ist, dachte ich eigentlich heute vormittag schon deutlich gemacht zu haben.

Wenn Du keine Hilfe willst/brauchst und uns nur über Deine Fortschritte auf dem Laufenden halten willst, brauchen wir natürlich auch keine präzisen Angaben ...
 
Ich bezog mich auf die Zeilen aus der Eingangsmail. Ich hab mir das Support-File angeschaut und dort geht hervor, dass die Registrierung beim
Registrar scheitert.


ua3 (<snip>@sip.personal-voip.de, sipiface=voip): not registered timeout 0 -- reachability 0 % (overvoip)
3: RX: 0 bytes, 0 pkts, TX: 0 bytes, 0 pkts, Lost packets: 0
3: Outgoing Calls: 0 attempted, 0 answered, 0 connected, 0 failed
3: Incoming Calls: 0 received, 0 answered, 0 connected, 0 failed
3: Overall Calls: 0 dropped, Total Call Time = 0:00

Wohingegen der Nachrichtenaustausch ganz ordentlich ausschaut:

2014-11-22 15:26:34.722 - OUT: my=192.168.178.1%17:5060 peer=46.182.250.45 port=5060 UDP, sipiface=voip tcclass=sip, netmark=0:
REGISTER sip:sip.personal-voip.de SIP/2.0
Via: SIP/2.0/UDP 10.x.x.x:5060;rport;branch=z9hG4bK941D6EC334F8A125
From: <sip:<snip>@sip.personal-voip.de>;tag=2897960041
To: <sip:<snip>@sip.personal-voip.de>
Call-ID: [email protected]
CSeq: 6 REGISTER
Contact: <sip:<snip>@10.x.x.x;uniq=542A633B6379B81F9D01175682D43>
Max-Forwards: 70
Expires: 1800
User-Agent: AVM FRITZ!Box 6490 Cable (kdg) 141.06.10 TAL (Sep 3 2014)
Supported: 100rel,replaces
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0


Und ja .. inder Tat schwimme ich. Finds auch brutal unangenehm, dass KD die Box so ausliefert. Das mindeste was ich beim Update erwarte ist, dass das was vorher funktionert auch weiter funktionert.

Edit: komischerweise heißt hier ua3 was im importierten File ua4 heißt !? Im Supportfile wird bei 0 losgezählt .. in der Konfigdatei bei 1.

Edit 2: Auch wenn ich hoffnungslos erscheine .. möchte ich mich trotzdem für die hilfreiche Begleitung bis hier her bedanken!
 
Zuletzt bearbeitet:
Ich hab jetzt mal ein Windows-SIP-Client installiert um meinen Account beim VoIP-Anbieter zu testen. Womöglich blockt KDG SIP insgesamt, denn damit klappt die Registrierung auch nicht. Ich dreh durch!
 
Ich bezog mich auf die Zeilen aus der Eingangsmail.
Hoffnungslos oder hoffnungsvoll ist egal, Dir soll ja gerne geholfen werden ... aber die o.a. Bemerkung zeigt, daß Du den Kern meiner "Kritik" trotzdem nicht verstanden hast. Selbst wenn ich mir die Reihenfolge aus dem ersten Beitrag vorstelle (das mit der Reihenfolge war auch nur zur Verdeutlichung für Dich, die ist ziemlich identisch und wird bei Schreiben der Datei durch die Firmware automatisch vorgegeben) ... woher soll man wissen, was Du unter "die ersten Zeilen" verstehst ? Die ersten zwei, die ersten zwanzig ? Ich hoffe, Du siehst das Problem ... ;)

Wohingegen der Nachrichtenaustausch ganz ordentlich ausschaut:
Ok, das ist mal das erste SIP-REGISTER (schließe ich aus fehlendem "Authorization:"-Header). Das sagt aber leider noch gar nichts, außer daß der Registrar stimmt und u.U. auch noch die Nummer, wenn ich mal unterstelle, daß da anstelle von "<snip>" die richtige Rufnummer steht.

Nun ist es aber mal so, daß da als erstes mit 99% Wahrscheinlichkeit ein "Unauthorized" mit einer Nonce für die Authentifizierung zurückgegeben wird und die Box dann erneut (diesmal mit Authentifizierung) ein REGISTER macht ... erst die Antwort auf diesen Request liefert dann mit dem Cause einen Hinweis auf die Ursache des Fehlers. Bei Dir ist das aber auch gar nicht die Ursache des Problems ...

Zweitens fällt nämlich auf, daß diese Registrierung von einer Adresse auf einem 10.0.0.0/8-Netz kommt, was bei KDG für die netzinterne Telefonie verwendet wird. Also versucht die Box, diese Nummer mit der KDG-Adresse für das "voip+tr69"-Interface (steht auch irgendwo in den Support-Daten) anzumelden und das ist falsch. Um so wichtiger wird es wieder, daß Du die genauen Einstellungen (nicht die Werte bei den Credentials, die interessieren niemanden, aber beim Rest der Einstellungen ist da nichts "geheim") darlegst. Die zusätzlichen SIP-Accounts müssen sich über das "internet"-Interface mit der öffentlichen IP-Adresse beim Provider registrieren, wie die Einstellung dafür heißt, weiß ich im Moment auch nicht ... wenn ich sie sehe, erkenne ich sie.

Und ja .. inder Tat schwimme ich.
Um so wichtiger ist es, nicht einfach auf gut Glück zu probieren und sich Hilfe zu suchen ... die findest Du i.d.R. hier auch, mußt sie aber schon mit "ordentlichen" Informationen versorgen, auch wenn das etwas mehr Schreibarbeit und vor dem Absenden ein erneutes Lesen unter dem Aspekt "Ich habe erst einmal keine Ahnung, was der Autor mir sagen will ... kriege ich das aus dem Text eindeutig heraus ?" erforderlich macht. Mehrere Roundtrips, bis das eigentliche Problem erkannt ist nach mehrmaligem Nachfragen, machen am Ende nicht nur Dir zusätzliche Arbeit, sondern auch allen, die Dir helfen sollen. Erst mal Schluß mit der "Belehrung", ich konnte es mir nur angesichts des ersten Zitats oben und meiner Bemerkung heute vormittag doch nicht ganz verkneifen.

Finds auch brutal unangenehm, dass KD die Box so ausliefert. Das mindeste was ich beim Update erwarte ist, dass das was vorher funktionert auch weiter funktionert.
Macht es ... schließ' die 7270 hinter der 6490 an und Du kannst wahrscheinlich sogar die Konfiguration so lassen (die KDG-Nummern halt deaktivieren). Daß es nicht ohne weiteres möglich ist, in einer DOCSIS-Box von KGD eigene SIP-Accounts zu verwenden, steht hier, im halben Internet, im kdg-forum.de und selbst bei den angeblichen Helden.

Auch wenn ich hoffnungslos erscheine .. möchte ich mich trotzdem für die hilfreiche Begleitung bis hier her bedanken!
Gern geschehen und kein Grund zur Aufgabe ... geh' einfach vor dem Speichern Deinen Text noch einmal durch, überlege Dir, ob Du ihn selbst verstehen würdest, wenn Du ihn nicht geschrieben hättest und dann sollte das hier am Ende auch zu einem akzeptablen Ergebnis führen.

Wenn Du verfremdest - das solltest Du auch tun - dann bitte so, daß man noch eine Vorstellung hat, was da eigentlich steht. Unter "<snip>" kann ich mir nichts vorstellen, unter "0123-45678" eine Telefonnummer und unter "max.mustermann" (oder "alice" / "bob" o.ä) einen Benutzernamen. Bei der Gelegenheit solltest Du auch noch einmal die 10.0.0.0/8-Adresse nachbearbeiten, die ist eineindeutig für Deinen Anschluß zu dem anzunehmenden Zeitpunkt und ermöglicht es zumindest dem Provider, Dich genau zu identifizieren (bzw. den Anschluß). Und auch da würde für das Verfremden dann gelten, daß ein Ersetzen durch "*.*.*.*" deutlich weniger Sinn macht, als ein "10.1.2.3", wo man dann den Fehler (falsches Interface) noch erkennen kann.

EDIT: Auch die Bemerkung "denn damit klappt die Registrierung auch nicht." ist klassisch. Wenn ich Dir jetzt sage: "Mein Auto fährt nicht.", was rätst Du mir dann ?
Normalerweise gibt es einen Fehlercode, wenn etwas nicht funktionieren will, je nach Windows-SIP-Client (auch die Information, welcher das genau ist, gehört einfach automatisch in so ein Posting hinein) auch eine Debug-Funktion mit genaueren Angaben oder wenigstens ein Log-File. Es bringt auch nichts, das "hoffnungsloser Fall" unterstreichen zu wollen ... geh' es systematisch an und gut ist. Daß KDG die SIP-Anmeldung von Clients hinter einer AVM-Kabelbox beschränken würde, wäre - mir persönlich - vollkommen neu ... da das dann kein "Vollanschluß" mehr wäre und dem Kunden die freie Wahl des VoIP-Anbieters komplett verwehrt wäre (wohingegen niemand KDG zwingt, ihm das direkt auf dem gemieteten Router zu ermöglichen), würde da sicherlich auch die BNetzA einschreiten.
 
Zuletzt bearbeitet:
Mit einem Fehler-Logfile kann ich leider nicht dienen, denn ich hab's mit dem SIP-Client hinbekommen und weiß nun, dass der Account ok ist und VoIP-Telefonie über Fremdanbieter prinzipiell über die Box funktionert (bist Du ja von ausgegangen). Grund für das Scheitern war, dass ich zwar bei SIP-Server sip.personal-voip.de aber bei Domäne nur personal-voip.de eingetragen hatte. Einzige Info die bleibt ist die oben zitierte aus dem Support-File. Zwecks Wiedererkennung ist nachfolgend eines der Profile. Die mit * gekennzeichneten Zeilen hab ich experimenteller Weise eingetragen - nichts davon sollte nötig sein.

Code:
            ua6 {
                    enabled = yes;
                    username = "123456";
    *               authname = "123456";
                    passwd = "aBcDeFg";
                    registrar = "sip.personal-voip.de";
                    ttl = 30m;
                    sipping_enabled = no;
                    sipping_interval = 280s;
                    name = "03055555444";
    *               providername = "sip.personal-voip.de";
                    with_displayname = no;
                    dtmfcfg = dtmfcfg_automatic;
                    rtpevent_keep_packetrate = no;
                    register_failwait = 0w;
                    register_failwaitmax = 30m;
    *               stunserver = "stun.personal-voip.de";
                    stunserverport = 3478;
                    use_internat_calling_numb = no;
                    is_nat_aware = no;
                    localip = 0.0.0.0;
                    protocolprefer = protocolprefer_ipv4only;
                    ignore_received_header = no;
                    always_clir = no;
                    clirtype = clir_none;
                    colptype = colp_none;
                    clipnstype = clipns_off;
                    vad_enabled = no;
                    only_one_dialog = no;
                    presence_supported = no;
                    mwi_supported = yes;
                    ccbs_supported = no;
                    reg_support = regsupport_auto;
                    packetization = packetization_fixed;
                    tx_packetsize_in_ms = 30;
                    xrtp_periodic = 0;
                    reject_refer = yes;
                    no_register_fetch = no;
                    do_not_register = no;
                    only_call_from_registrar = no;
                    invite_without_register_allowed = no;
                    outboundproxy = "";
                    outboundproxy_without_route_header = no;
                    factory_3pty_uri = "";
                    no_hold_speech = no;
                    dditype = ddi_none;
                    ddireception = "";
                    alias_head_number = "";
                    cfxsignaling = cfx_standard;
                    backup_wanted = no;
                    use_session_timer = no;
                    use_rport = yes;
                    add_rtpmap_for_all_codecs = no;
                    answer_only_one_codec = no;
                    without_annexb_no = no;
                    srtp_supported = no;
                    use_488_for_no_t38 = no;
                    g726_via_rfc3551 = no;
                    no_g726_32_offer_with_pt2 = no;
                    enable_3xx = yes;
                    t38_reinvite_from_remote = no;
                    use_t38version0 = no;
                    rtcp_xr_media_attribute = no;
                    ptime_a_attribute = yes;
                    read_p_asserted_identity_header = no;
                    route_always_over_internet = no;
                    gui_readonly = no;
            }
 
Zuletzt bearbeitet:
Dann versuche es noch einmal mit "route_always_over_internet = yes;". Sollte das nicht funktionieren, wird aus "showshringbuf sip" (das ist das Log, wo das vorherige REGISTER auch her kam) die passende Anfrage inkl. der Antwort des Providers benötigt (natürlich von dem aktuellen Versuch und nicht aus den vorherigen Support-Daten).
 
Dann versuche es noch einmal mit "route_always_over_internet = yes;".

Großartig .. ich kann nun über die Vorauswahl raustelefonieren!!!

Danke :)

Was noch nicht so will:
- Die Kuller sind nicht grün
- Auf der Übersichtsseite sind es weiterhin 3 und nicht 6 aktive Rufnummern
- Die neuen Rufnummern stehen nicht für Wahlregeln zur Verfügung

Ich hatte gehofft, dass sich Letzteres erledigt, wenn die Accounts sich ordentlich registrieren.
 
- Die Kuller sind nicht grün
- Auf der Übersichtsseite sind es weiterhin 3 und nicht 6 aktive Rufnummern
- Die neuen Rufnummern stehen nicht für Wahlregeln zur Verfügung
Ich hatte gehofft, dass sich Letzteres erledigt, wenn die Accounts sich ordentlich registrieren.
Die Voraussetzungen für die "grüne" Anzeige habe ich schon weiter vorne aufgelistet als Auszug aus "fon_num_list.lua". Eine Eigenschaft der selbst eingerichteten Nummern paßt noch nicht, welche kann ich wieder nicht raten, so viele kommen ja nicht in Frage (registered oder activated).
Daraus leitet sich dann die fehlende Akzeptanz als "vollwertige" Nummer ab. Das Routing über die "internet"-Connection anstelle von "voip+tr069" sollte nicht der entscheidende Unterschied sein. Deshalb hatte ich auch irgendwo vorher geschrieben, daß man es nicht auf die leichte Schulter nehmen sollte, wenn die "LED nicht leuchtet" im GUI.

Der systematische Vergleich zwischen den KDG- und den eigenen Nummern anhand der Support-Daten sollte eigentlich Aufschluß geben ... ist halt nichts, was man mal nebenbei erledigt.
 
Hab mir die beiden Profile mal nebeinanandergestellt .. kann beim ersten Versuch aber noch kein Erfolg vermelden. Mit fällt bei den Wahlregeln gerade auf, dass ich alle Mobiltelefonate zu den drei KDG nummern schicken kann aber auch zu einer Einstellung namens Internet. Was mag "Internet" bedeuten?

Werde morgen weiter versuchen die Lampen an zu machen .. dauert immer so lange mit dem Neustarten.
 
Zuletzt bearbeitet:
@daniello

Ist schon Lustig dein Anzeige Problem das hatte ich noch nie und kann
es auch nicht ändern, aber du kannst mal den FBeditor 0.6.9.5 Testen erstellt mit Eclipse und Java 1.6
oder die letzte FBEditor Version 0.7.0.5 erstellt mit NetBeans 8 und Java 1.7
Die beiden Versionen 0.6.9.5 und 0.7.0.5 sind gleich der einzige unterschied ist die Entwicklungsumgebung.

Der FBeditor 0.7.2 erstellt mit Eclipse und Java 1.6 ist die letzte Version
und wird mit den Aktuellen Versionen 0.6.9.5 und 0.7.0.5 abgelösst.

Gruß Erwin ;)
 
Der FBeditor 0.7.2 erstellt mit Eclipse und Java 1.6 ist die letzte Version
und wird mit den Aktuellen Versionen 0.6.9.5 und 0.7.0.5 abgelösst.
Gruß Erwin ;)

Verstehe ich richtig, dass 0.7.0.5 aktueller sein soll als 0.7.2 ?
 
Ja denn bei Version 0.7.2 Fehlt die Funktion mit Kennwort für Sicherungsdatei

FBEditor 0.7.2 ist die letzte Version ohne Kennwort für Sicherungsdatei,
und wird von mir nicht mehr weiter Entwickelt.

Was mir noch aufgefallen ist, Starte doch mal den FBEditor mit dem Schalter -d32
Code:
-d32          Verwendet ein 32-Bit-Datenmodell, sofern verfügbar
-d64          Verwendet ein 64-Bit-Datenmodell, sofern verfügbar
vielleicht Hilft das.

java.exe -d32 -jar fbeditor.jar
javaw.exe -d32 -jar fbeditor.jar

Gruß Erwin ;)
 
Zuletzt bearbeitet:
@Pikachu:
daniello schrieb:
Java Version ist > 8 .. soviel weiß ich.
1. Hast Du je selbst mit Java Runtime > 7 getestet ? Wenn ja, funktioniert es auch da reibungslos ?

2. Ist in der 0.7.0.5 dann das richtige Berechnen der Prüfsumme drin oder nicht ?

Ich will die Leute bei Fragen dazu nicht in die falsche Richtung jagen ... und bisher hat noch bei jedem der 0.7.2 mit den "no telnet daemon"-Boxen von AVM am ehesten funktioniert; wenn jemand kein Linux mit Shell hat, nutzen ihm meine Skripte für die crc32-Berechnung nichts und ich verweise dann i.d.R. auf den FBEditor (und nicht auf die auch irgendwo noch existierenden Perl-Skripte). Bisher eben (aus Unkenntnis) auf die 0.7.2 ... kann ich jetzt also auch auf die andere hinweisen ?
 
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.