Führende Nullen werden abgeschnitten nach Update auf 6.3.0.19

  • Hallo zusammen,


    ich habe heute unsere starface von 5.8.0.15 auf Version 6.3.0.19 upgedated.
    Der Updateprocess lief ohne besondere Vorkommnisse.


    Jetz haben wir folgendes Problem:
    Beim heraustelefonieren müssen wir zwei zusätzliche Nullen (andere Ziffern habe ich nicht ausprobiert) angeben.


    Beispiel:
    Wir wollen 0049 1234 56789 anrufen, müssen aber 000049 1234 56789 wählen.
    Nur Ortsvorwal verhällt sich genau so.
    Wir wollen 01234 56789 anrufen, müssen aber 0001234 56789 wählen.


    Bisher hatte ja alles Funktioniert und in der Updatebeschreibung steht, dass man alle Module und Weiterleitungen international angeben soll, bevor man das Update startet.
    Das habe ich kontrolliert und lediglich zwei Weiterleitungen auf Handys verändert, sonst war schon alles mit 0049 angelegt.


    Hat jemand eine Idee, woran das liegen kann?



    Gruß
    Sven

  • Moin,
    keine Ahnung, aber als Idee gucke dir mal 2 Punkte an:
    1. Leitungen --> Allgemein --> Amtsholung
    2. Leitungen --> Leitungen --> Erweitert --> Leitungspräfix
    beides sollte leer sein, um nicht vorweg wählen zu müssen. Zumindest verstehe ich es so.
    Mit freundlichem Gruß
    Andreas

  • Hallo Andreas,


    kleine Anmerkung / Korrektur:


    Der Hinweis unter 2. stimmt so nicht - der Leitungspräfix dient nur dem gezielten Auswählen einer bestimmten Leitung, wenn manmit mehreren Providern arbeitet. Dort kann 1 ... 9 drin stehen - die Angabe kann dann optional mit **X* vorgewählt oder auch weggelassen werden - das Problem wie beschrieben kommt ganz sicher nicht von möglichen Einträgen beim Leitungspräfix.


    Sven: man müsste sich das mal komplett anschauen können - im Grunde kann man in diesem Zusammenhang nicht so viel "falsch" machen, um so einen Effekt hervorzurufen.


    "Doofe" Frage: wurde die Anlage nach dem Update mal komplett neu gestartet? Wenn NEIN, ist das Problem nach einem Neustart (Server) noch vorhanden?

  • Herzlichen Dank für Eure Antworten.


    Die beiden von Schubbie genannten Einstellungen hatten wir bereits überprüft, beide waren wie erwartet leer.
    Ebenso haben wir die Anlage mehrere Male neu gestartet.


    Außerdem haben wir das letzte Backup (Version 5.8.0.15) neu eingespielt und später sogar den SIP-Provider rausgeschmissen und alle Daten frisch eingegeben. Das Ergebnis war das gleiche.
    Wir haben uns dann Entschieden es mit Version 6.2.0.15 zu Versuchen. Diese hatten wir bereits auf einem Installstick bereitgehalten. Nachdem dann andere Fehler auftraten haben wir noch auf Version 6.2.0.17 upgedated. Jetzt scheint erst mal wieder alles zu funktionieren.


    Dennoch bin ich von der Softwareentwicklung schwer enttäuscht.



    Für diejenigen, die sich für die gemachten Erfahrungen interessieren, hier ein kleiner Abriss darüber.
    Ich kann nicht sagen ob wir ein Einzelfall sind, oder nicht. Auf uns machte die Aktion Softwareaktualisierung jedenfalls den Eindruck, dass die Software nicht getestet wird, bevor sie auf den Kunden losgelassen wird. Grundfunktionen einer Telfonanlage waren in einer Software-Version gar nicht nutzbar. Siehe unten.


    Zustand vor Aktualisierung:
    Starface Advanced mit Software-Version 5.8.0.15
    13 User-Konten, eines davon analges Fax über SIP-analog-Wandler
    15 angemeldete Telefone (Gigaset 700/900, Polycom Soundstation)
    Rufnummernblock bei easybell mit 100 Durchwahlen (0-99)
    2 Gruppen zur Rufweiterschaltung (Empfang/Zentrale und Erweiterter Empfang/Vertretung)


    Ich gehe davon aus, dass diese Konfiguration für ein kleines, wachsendes Unternehmen durchaus normal ist.



    Durchführung Update:
    - Mit Modul STARFACE Archivierung Daten ausgelagert
    - Manuell ein Backup ausgelöst
    - Updateprozess auf Version 6.3.0.19 im Webinterface gestartet.



    Nachdem der Update-Prozess beendet war, sollte getestet werden.
    - Alle Telefone haben sich Erfolgreich mit der Starface verbunden.
    - Eingehende Anrufe klappten
    - Ausgehende Anrufe machten Probleme, entweder Fehler "Nummer existiert nicht", oder falsch verbunden.


    Fehlersuche:
    Zunächst war unklar, was beim Heraustelefonieren schief geht. Es stellte sich dann aber heraus, dass bis zu zwei führende Nullen unterschlagen wurden.
    Interen Anrufe klappten
    Innerörtliche Anrufe klappten
    ÜberÖrtliche Anrufe klappten nicht mehr.
    Aus gewählt 01234 56789 wurde Innerorts 123456789
    Aus gewählt 0049 1234 56789 wurde Innerorts 49123456789


    Um die Richtigen Anschlüsse zu erreichen mussten zwei Nullen vorgewählt werden, also 0001234 56789 bzw. 000049 1234 56789
    Darauf muss man erst einmal kommen(!!!), denn eingehende Anrufe wurden richtig angezeigt, ohne zusätzliche Nullen.


    - Alle Einstellungen zur Amtsleitung/SIP-Provider wurden überprüft, aber sie waren wie vor dem Update konfiguriert.
    - Etliche Versuche mit veränderten Einstellungen, die alle keine Änderung oder eine Verschlimmerung nach sich zogen.
    - Irgendwann wurde Entschieden das Backup erneut einzuspielen --> Gleiches fehlerhaftes Verhalten.
    - Löschen der Provider-SIP-Einstellungen; komplett neues Providerprofil angelegt und SIP-Daten neu eingegeben. Leider müssen dann auch alle Rufnummern und Weiterschaltungen/Umleitungen wieder zugeordnet und eingestellt werden. Aber der Fehler blieb genau so erhalten.
    Weitere Tests wurden in dieser Version nicht mehr durchgeführt.


    - Neuinstallation der Starface Version 6.2.0.15 vom USB-Stick.
    - Einspielen des Backups.
    - Testen ergab Probleme mit der Rufweiterschaltung, Module Ansage vor Melden und Zeitgesteuerte Umleitung funktionierten nicht.
    - Update auf Version 6.2.0.17


    - Die Rufweiterschaltung lief wieder, die beiden Moduel mussten neu angelegt werden, bevor sie wieder funktionierten.
    - Die Nachtschaltungstasten (BLF) mussten mit dem neuen Modul (Zeitgesteuerte Umleitung) belegt werden.
    - Alle weiteren Tests waren erfolgreich.


    Wir müssen also davon Ausgehen, dass die Version 6.2 seit Ihrem erscheinen drei Monate lang, grundlegende Funktionen wie Rufweiterschaltung und Zeitgesteuerte Umleitung (Nachtschaltung), nicht richtig unterstützte. Werden Grundlegende Funktionen bei Starface nicht getestet, bevor die Software bereitgestellt wird? Schließlich haben wir keine komplizierte Konfiguration, daran sollte es also nicht gelegen haben.


    Gruß
    Sven

  • Die Rufnummernthematik klingt seltsam. Wurden vielleicht unter 5.8.0.15 manuelle Anpassungen am Rufnummernformat vorgenommen (per Modul oder Leitungskonfiguration), die dann nicht updatesicher waren?
    Die Signalisierung der Rufnummern ohne die Nullen ist nicht ungewöhnlich. Die Übermittlung einer 000049... hingegen schon. Das klingt ganz und gar nicht nach einem Standard-Setup.


    Dass die Module "Ansage vor Melden", "Zeitgesteuerte Umleitung" und Rufweiterleitungen unter 6.2 nicht funktionieren, kann ich nicht bestätigen. Das klingt sehr danach, als wären beim Umstieg von 5.8 auf 6.2 die Rufnummern innerhalb der Module nicht auf das internationale Rufnummernformat angepasst worden.
    Das ist ein manueller Vorgang, auf den in den Release Notes und beim Update hingewiesen wurde. Wenn man das natürlich nicht macht, werden rufnummernabhängige Regeln natürlich nicht mehr ausgeführt. Das hat aber nichts mit halbfertiger Software zu tun, als mit Usern, die Anweisungen beim Update nicht befolgen.

  • Hallo Sven,


    Deine Frage kann man leicht beantworten: natürlich werden die Versionen vor Erscheinen ausführlich getestet - ab einem bestimmten Zeitpunkt im übrigen auch unter Einbeziehung externer Tester. Vor Erscheinen der 6.3.x-Final ist hier im Forum schon bereits kurz die stabile Funktion dieser Version angesprochen worden.


    Entsprechend hatten wir z.B. hier die Version 6.3.x schon längere Zeit auf zwei Installationen unter sogar eher sehr komplexen Konstellationen am Laufen (viele Leitungen, unterschiedliche Provider, sehr viele aktive Module unterschiedlichster Quellen usw.). Bei uns lief das Ganze auf einer Compact und Advanced völlig problemfrei (wie die Version 6.2.x in allen wesentlichen Punkten auch gut funktionierte).


    Die beschriebenen Fehler sind tatsächlich SEHR merkwürdig und sind zu hinterfragen, zumal die beschriebene Konstellation eher einfach und gar nicht sehr komplex ist.


    Ich vermute Du bist nicht selbst Starface-Partner? Hast Du denn einen Partner, der sich das Ganze mal anschauen kann?


    Bei den irgendwie selbst konfigurierten Anlagen hatte ich bereits mehrfach die verrücktesten Konfigurationsfehler gesehen - manchmal sind es unscheinbare Sachen, die die komischsten Effekte hervorrufen.


    Die benannten Module hatten wir und/oder Kunden durchgehend seit Erscheinen der 6.2.x bzw. hier bei der 6.3.x in Betrieb und keine Probleme damit feststellen können.

    Was hier allerdings niemand gemacht hat, ist ein Sprung von 5.8.x auf 6.2.x - vielleicht ist das suboptimal.
    In allen Fällen in unserem Umfeld waren im Grunde auch die Zwischenschritte, also alle verfügbaren Updates installiert gewesen und nicht so ein übergreifender Riesensprung gemacht worden.


    Nachdem das Verhalten Deiner Installation insgesamt sehr fragwürdig ist, würde ich eventuell ein richtige Neuinstallation ohne Einspielen eines Backups in Betracht ziehen um Altlasten wirklich sicher auszuschliessen. Das macht natürlich etwas Arbeit - ist aber bei der beschriebenen Konstellation gerade noch überschau- und handelbar.

  • Hallo Fabian,


    Ich habe die Anlage vor ca. 2 Jahren hier im Hause installiert. Wenn ich mich recht erinnere war es damals noch eine 5.6.
    Eine besondere Anpassung habe ich nicht vorgenommen. Es gab allerdings ein Problem mit dem easybell-Profil. Hier musste eine Einstellung auf der Profil-Seite geändert werden, ich meine es war die Portnummer (5064), danach lief die SIP-Verbindung.
    Die ersten sieben Benutzer sowie zwei Gruppen wurden angelegt. In den Benutzereinstellungen wurden Umleitung bei Besetzt und bei Zeitüberschreitung auf die Zentralgruppe1 eingerichtet.
    In der Zentralgruppe1 wurde Umleitung bei Besetzt und bei Zeitüberschreitung auf Zentralgruppe2 eingerichtet.
    In der Zentralgruppe2 wurde Umleitung bei Besetzt und bei Zeitüberschreitung auf Voicemail eingerichtet.
    Die Nachtschaltung auf die Voicemail wurde über Modul "Zeitgesteuerte Umleitung" realisiert. Als eingehende Rufnummer wurden die interne und die externe Zentralnummer eingetragen.
    Über das Modul "Ansage vor Melden" wurde eine Wartemusik mit stummer, kurzer Ansage realisiert.


    --> Grundkonfig fertig.


    Die einzige Besonderheit:
    Eine zweite Netzwerkkarte (eth1) wurde eingebaut, um vom Computer-Netz (V-Lan) auf die Starface zugreifen zu können. Mit eth0 hängt die Anlage sowie alle Telefone in einem eigenen Netzwerk (V-Lan) mit separatem Internetrouter.


    In den vergangenen zwei Jahren wurden dann lediglich noch einige Benutzer und Telefone hinzugefügt.


    Der Versuch ein Telefon über eth1, inkl. Routing in ein anderes IP-Netz, anzubinden klappte leider nicht. Zusätzliche Routingeinträge in der Starface wurden vorgenommen, aber eine stabile Verbindung ist selbst im Netz von eth1 nicht möglich gewesen. In den Provisionierungsdaten waren bereits die flaschen Daten von eth0 hinterlegt, diese konnte man im Telefon zwar manuell ändern, aber eine Stabile verbindung ist dennoch nicht zustande gekommen. Und ja, in der Telefonconfig wurde der zweite Adapter/die zweite IP-Adresse eingestellt, ohne Erfolg. Und bevor die Frage kommt: Das Routing im Computernetzwerk funktioniert ansonsten tadellos.


    Zum Thema Anweisungen beim Update muss ich mitteilen, dass ich durchaus die Anweisungen gelesen habe.
    Zum Beispiel resultiert das Exportieren der Verbindungsdaten aus der Anweisung. Ich habe jedenfalls alle Seiten in der Admin-Konfiguration geöffnet und nachgesehen ob hier Telefonnumern in das Internationale Format 0049..... geändert werden müssen. In der kleinen Konfiguration ist das problemlos schaffbar. Bis auf zwei iFMC-Einträge gab es da aber auch nichts zu ändern. Im Modul "Musik anstatt Klingelton" (Ansag vor Melden) steht ein "*" und im Modul "Nachtschaltung" (Zeitgesteuerte Umleitung) stehen die interne Zentrale und die externe Zentralnummer ohne Landes und Ortsvorwahl, aber es handelt sich auch nur um ein Nummernmuster, das ja jetzt auch so funktioniert, und ich meine mich erinnern zu können, dass es bei der Inbetriebname ein Problem mit der vollständigen Nummer gab. Damit wären die Module aber auch bereits erledigt. Also wird das auch nicht das Problem sein.


    Und nebenbei Bemerkt:
    Bei unseren Recherchen sind wir im Internet auch auf Beiträge anderer gestoßen die ähnliche Probleme mit den Modulen hatten, die erst mit dem Update auf 6.2.0.16 behoben wurden, denn da wurden die Module aktualisiert. Und auch wir hatten nach dem Update auf 6.2.0.17 plötzlich keine Probleme mehr mit den Modulen, außer dass wir diese noch einmal mit den gleichen Daten neu anlegen mussten. Das hatten wir aber beriets unter 6.2.0.15 erfolglos versucht, weshalb ich nicht sagen kann ob das neu anlegen auch notwendig gewesen wäre, hätte man direkt bis 6.2.0.17 upgedated.


    Alles in allem, bin ich davon überzeugt, dass wir alles mögliche getan haben um ein erfolgreiches Update durchzuführen.
    Leider sollte es dennoch anders kommen, und die Erfahrungen haben unser Vertrauen in das Produkt schwer erschüttert.



    Gruß
    Sven

  • Hallo zusammen,


    bevor ich an Kundenanlagen ran gehe, habe ich heute bei uns das Update eingespielt.
    Bei der dritten falschen Person beim ausgehenden Anruf habe ich dann mal genauer geschaut.
    Wir haben das gleiche Problem wie Sven.


    In der Anlage selbst fällt mit auch nichts auf, die Rufnummern im Log sehen aus wie immer.
    Da wir Easybell hauptsächlich benutzen, fällt dort im Log dann aber auf was das eigentliche Problem ist.


    Vorher:
    0891234567


    Nachher:
    0204549891234567


    Lösung habe ich bislang noch keine, Setup ist aus meiner Sicht soweit auch korrekt.
    An der Starface Hotline ist aber auch kein durchkommen.....



    Gruß
    Sascha

  • Hallo Ulf,


    wir sind kein Starface-Partner und mir ist auch keiner bekannt, mit dem wir bei Bedarf in Kontakt treten können.
    Wie du schon vermutet hast ist die Konfiguration nicht sehr komplex. In meinem Post von 13:22 habe ich das näher beschrieben.


    Warum wir keine Zwischenschritte gemacht haben hat verschieden Ursachen, "Never change a running System" spielt dabei sogar eher eine untergeordnete Rolle.
    In der Dokumentation stand aber, dass es ab 5.6 möglich ist die Versionen zu überspringen, darauf haben wir uns natürlich verlassen.


    Wenn ihr mit unterschiedlichen Provider testet ergibt sich jetzt natürlich die Frage, ob auch easybell dabei ist?
    Und jetzt kommt der Klopper: Easybell hat uns mitgeteilt, das sie Veränderungen am SIP-Zugang vornehmen. Wir können also nicht mal sicher sein ob der Nullen-Fehler in der Starface oder evtl. beim Provider stattgefunden hat. Erneut testen können wir das nicht, unsere Anlage ist nach dem langen Ausfall am Samstag erst einmal wieder produktiv geschaltet.


    Gruß
    Sven

  • Hallo Sascha,


    die Nachhernummer beginnt mit 02045, das ist die Vorwahl von Bottrop-Kirchhellen, wir sind hier in Mülheim a.d. Ruhr, quasie nebenan. Seit Ihr auch hier in der Nähe? Evtl. ist das ja tatsächlich ein Problem von Easybell, auch unser Provider.


    Gruß
    Sven


  • Die einzige Besonderheit:
    Eine zweite Netzwerkkarte (eth1) wurde eingebaut, um vom Computer-Netz (V-Lan) auf die Starface zugreifen zu können. Mit eth0 hängt die Anlage sowie alle Telefone in einem eigenen Netzwerk (V-Lan) mit separatem Internetrouter.


    In den vergangenen zwei Jahren wurden dann lediglich noch einige Benutzer und Telefone hinzugefügt.


    Der Versuch ein Telefon über eth1, inkl. Routing in ein anderes IP-Netz, anzubinden klappte leider nicht. Zusätzliche Routingeinträge in der Starface wurden vorgenommen, aber eine stabile Verbindung ist selbst im Netz von eth1 nicht möglich gewesen. In den Provisionierungsdaten waren bereits die flaschen Daten von eth0 hinterlegt, diese konnte man im Telefon zwar manuell ändern, aber eine Stabile verbindung ist dennoch nicht zustande gekommen. Und ja, in der Telefonconfig wurde der zweite Adapter/die zweite IP-Adresse eingestellt, ohne Erfolg. Und bevor die Frage kommt: Das Routing im Computernetzwerk funktioniert ansonsten tadellos.


    Die STARFACE ist kein Router und das, was da gemacht wurde, ist ein nicht supportetes Szenario. Das sollte einem klar sein, wenn man solche Dinge anfängt. Insbesondere Themen wie Firewalling/Security Advisor, Dienstebindung an den Interfaces, etc. sind Themen, auf die das Auswirkungen hat.
    Wenn das Routing im Netzwerk tadellos funktioniert, warum routet das Standardgateway nicht einfach zwischen den Netzen?



    Alles in allem, bin ich davon überzeugt, dass wir alles mögliche getan haben um ein erfolgreiches Update durchzuführen.
    Leider sollte es dennoch anders kommen, und die Erfahrungen haben unser Vertrauen in das Produkt schwer erschüttert.


    Ich finde es schwierig, wenn einerseits gravierende "Anpassungen" am Produkt vorgenommen werden, die so nicht supportet sind und auch entsprechend nicht getestet werden können und man sich dann darüber beschwert "dass die Software nicht getestet wird, bevor sie auf den Kunden losgelassen wird".


    Vielleicht schauen wir uns aber die Leitungskonfiguration genauer an... ich vermute, dass die Probleme dort begraben liegen. Poste am Besten mal die Konfiguration und die PBX-Log-Ausgabe eines Beispielanrufs.

  • Hi,


    spontan würde ich auf die Einstellung des ausgehenden Rufnummernformates als Fehlerursache tippen (Leitungsbereich -> profil editieren -> "kopieren" Button klicken -> wert verändern und speichern -> dieses neue Profil zur Leitung zuweisen). Zuerst würde ich als Wert "0011 (222) xxxx" probieren.

    Quality Assurance


    STARFACE GmbH | Adlerstraße 61 | 76137 Karlsruhe | www.starface.com

  • Hallo Miteinander,


    Ich hatte das Problem auch gerade mit meinen easybell trunks. Ich habe nun für ein und ausgehend 0011 (222) xxxx eingestellt. Seither funktioniert es wieder.


    Wo war nur der Hinweis im Update versteckt?


    Gruss Björn


  • Sven hat vorhin geschrieben:


    Zitat

    Easybell hat uns mitgeteilt, das sie Veränderungen am SIP-Zugang vornehmen


    Je nachdem wann diese Änderung durchgeführt wurde, könnte es sein dass es in das Release (und folglich auch den Release-Notes) garnicht hätte reinkommen können.

    Quality Assurance


    STARFACE GmbH | Adlerstraße 61 | 76137 Karlsruhe | www.starface.com

    Einmal editiert, zuletzt von TomAnson ()


  • Hallo Sven,


    Nein - easybell ist leider ausgerechnet nicht dabei ...


    Der Sprung von 5.8.x auf 6.2.x oder 6.3.x ist schon halbwegs gewaltig - da gab es einige Änderungen und es empfielt sich tatsächlich im Nachhinein diverse Dinge zu prüfen. Eventuell gibt es aber (wie gerade zu lesen war) auch schon einen Lösungsansatz.


    Diverse Partner tummeln sich erkennbar hier im Forum, gegebenenfalls bietet Dir sicher auch der Eine oder Andere seine Hilfe an. Gerne kannst Du auch mich in der kommenden Woche nochmal ansprechen, wenn noch Bedarf besteht - aktuell bin ich gerade zu einer Projektumsetzung bzw. Anbahnung in UK. Auf einen Starface-Partner bei Bedarf zurückgreifen zu können, dürfte in einigen Fällen ganz hilfreich sein - mich wundert immer wieder, wie viele Installationen dann eben doch völlig ohne Hintergrund installiert und genutzt werden. Insbesondere die nachträglich im Detail beschriebene Konstellation ist dann überdies so banal gar nicht ... aber das hatte schon Fabian ganz treffend angemerkt.

  • Könntest du bitte Screenshots der Modulkonfiguration als Post-Anhang hochladen (Rufnummern können gern vertuscht werden, nur die ersten paar Zeichen der Rufnummernfilter sind hier wichtig), dann könnte man geschwind drüber schauen ob bei der Konfiguration etwas anzupassen wäre.

    Quality Assurance


    STARFACE GmbH | Adlerstraße 61 | 76137 Karlsruhe | www.starface.com

  • Die STARFACE ist kein Router und das, was da gemacht wurde, ist ein nicht supportetes Szenario. Das sollte einem klar sein, wenn man solche Dinge anfängt. Insbesondere Themen wie Firewalling/Security Advisor, Dienstebindung an den Interfaces, etc. sind Themen, auf die das Auswirkungen hat.
    Wenn das Routing im Netzwerk tadellos funktioniert, warum routet das Standardgateway nicht einfach zwischen den Netzen?


    Die Starface fungiert nicht als Router! Sie hat lediglich zwei Netzwerkinterfaces.
    Es gibt bewusst ein Telefon-V-Lan, das aktuell nicht über Routing zu erreichen ist und über einen eigenen Router ins Internet geht. Das war vor zwei Jahren so gewünscht.
    Über eth1 haben die Administratoren die Möglichkeit an die Starface zu kommen. Wollte man das über normales Routing realisieren müsste man den dedizierten TK-Router zusätzlich aufbohren, was auch nicht gewünscht war.


    Ich finde es schwierig, wenn einerseits gravierende "Anpassungen" am Produkt vorgenommen werden, die so nicht supportet sind und auch entsprechend nicht getestet werden können und man sich dann darüber beschwert "dass die Software nicht getestet wird, bevor sie auf den Kunden losgelassen wird".


    Vielleicht schauen wir uns aber die Leitungskonfiguration genauer an... ich vermute, dass die Probleme dort begraben liegen. Poste am Besten mal die Konfiguration und die PBX-Log-Ausgabe eines Beispielanrufs.


    Da inzwischen wieder alles in älterer Version läuft wird das mit dem Beispiel-Logeintrag schwer und alte Einträge suchen macht wegen der Neuinstallation wenig Sinn.


    easybell-profile.jpg easybell-Provider.jpg easybell-Nummernraum.jpg easybell-Erweitert.jpg


    Gruß
    Sven

    2 Mal editiert, zuletzt von sven.lag ()

  • Was TomAnson und bezel geschrieben haben, haben wir nicht ausprobiert, Die Feldüberschrift heißt ja auch Rufnummernanzeige.
    Interessant wird jetzt allerdings die Frage nach der Rückruffunktion, klappt das immernoch auf beiden Seiten?


    Gruß
    Sven

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!