Anzeige der Namen aus dem Adressbuch (Rufnummernanzeige)

1st Official Post

    Folgende Varianten können im Telefonbuch gepflegt sein. Je nachdem, wie es der Benutzer eingibt oder vom vorhergehende System geliefert wird.

    1. 0170xxx

    2. 0049170xxx

    3. +49170xxx


    Am Yealink T46S und auch am Webclient und Softphone wird der Name aus dem Telefonbuch nur korrekt aufgelöst, wenn die Telefonnummer im Format 3 gepflegt ist.

    Kann ich das irgendwie ändern oder ist das ein Bug? Meiner Meinung nach ist es immer die gleiche Rufnummer und die STARFACE sollte das richtig auflösen und anzeigen können.

    Gegeben sei folgende aufzulösende Rufnummer: +49123456789

    Wie viele verschiedene Schreibweisen dieser Rufnummer können in einem Adressbuch existieren?


    0049..., +49..., 0

    0049 1234 56789, 0049 123456789, 0049 12345 6789, 0049 123456 789,...

    0049 1234 5678-9, 0049 1234 567-89, 0049 1234 56-789,...

    0049 12345 678-9, 0049 12345 67-89, 0049 12345 6-789,...

    0049 12345 678-9, 0049 12345 67-89, 0049 12345 6-789,...

    0049/12345/6789, 0049 12345/6789, 0049/123456789,...

    und so weiter... um es kurz zu machen: unglaublich viele!


    Um nicht für jede Rufnummer tausende Kombinationen prüfen zu müssen, muß man die Quelle (das Telefonbuch) normieren.

    Quote from roady1969

    [...]


    Und andere können das halt problemlos.

    Das halte ich für ein Gerücht, denn auch andere stehen vor dem selben Problem. Der einzige Weg daran vorbei ist, für jeden Adressbucheintrag und jede Rufnummer darin, eine normierte Version zu berechnen und zu speichern. Man benötigt also eine zweite, bereinigte Version, der Daten.


    So eine Bereinigung kann das estos MetaDirectory beim importieren machen – oder man macht es eben gleich richtig, auch wenn dazu erst einmal das Bewusstsein für das Problem geschaffen werden muß.

    fwolf

    Das ist ja mehr eine Frage des Queries/Algorythmus…


    Und wer meine Beiträge verfingt weiß, dass wir stark auf die komfortableren Systeme von den Bielefeldern setzen.


    Da geht das.

    Und zwar nicht nur mit deren Systemgeräten. Auch mit deren SIP Dect IP oder einfach SIP Telefonen.


    Warum also zweifeln?

    Der Informatiker würde sagen, das Problem, jede mögliche Schreibweise eines Textes gegen ein gegebenes unbekanntes Format zu vergleichen, ist NP-vollständig.

    Die Anzahl der notwendigen Vergleichsoperationen wächst stark exponentiell mit der Länge der Rufnummer und der möglichen Formate.


    Man kann natürlich immer eine Art Brute-Forcing machen, aber das ist in Anbetracht des Nutzens dumm, denn ich hatte ja bereits die eigentliche Lösung skizziert.
    Entweder normiert man seine Daten selbst oder das System (oder eine Zwischenschicht) muß es tun. Es ist also gut möglich, dass die "Bielefelder" diese Normierung durchführen. Aber dann haben wir eine zweite Datenbank geschaffen, die nur den Müll der ersten Datenbasis kaschiert.

    Deshalb nochmal die Frage: Warum macht man nicht auf das Problem aufmerksam (schafft das Bewusstsein), um es dann gleich richtig zu machen?


    Anstatt das Problem mit einer bereinigten Datenbankkopie zu erschlagen, könnte man nämlich einen ziemlich einfachen Normierungsalgorithmus auf die ursprüngliche Datenbank anwenden und die Daten säubern. Das abfragende System selbst ist an der Stelle raus, denn die Abfragen selbst müssen über Schnittstellen hinweg funktionieren.

    Ich erkläre seit mindestens über 10 Jahren ITU-Richtline E.123 & DIN 5008 und rede mir den Mund fusselig...


    Trotzdem versteht es keiner... Nicht mal große Telekommunikationsfirmen machen das richtig.


    Das ist eine Kurzform:


    Guten Tag allerseits,


    basierend auf unserem Gespräch eben:


    Also in korrekter Schreibweise nach ITU und DIN usw. dann so:


    +49 221 123456780


    0049 221 123456780


    Und so (oder halt mit „00“ statt“+“, ich präferiere aber das Plus-Zeichen):


    +49 221 12345678-0


    +49 221 12345678-11


    Es kann natürlich auch alles zusammengeschrieben werden:


    +49221123456780


    0049221123456780


    Langweilige, technische Hintergründe:


    Rufnummern und Routing
    www.msxfaq.de


    Maßgeblich ist die ITU-Richtline E.123


    E.164 – Wikipedia


    Und der Vollständigkeit halber RFC 3966:


    https://www.ietf.org/rfc/rfc3966.txt


    Für Deutschland: DIN 5008


    Telefonnummern in Briefen und Mails richtig schreiben
    Die Schreibweise von Rufnummern ist beispielsweise durch die DIN geregelt. Wir erklären, wie Sie eine Telefonnummer richtig schreiben.
    www.teltarif.de


    DIN 5008 – Wikipedia

    Deutschland

    Die folgenden Beispiele von internationalen Rufnummern enthalten den Ländercode 49, die Ortsnetzkennzahl 30, die Teilnehmerrufnummer 12345 und die Durchwahl 67:


    Schreibweise

    Bemerkungen






    +49 30 12345-67

    DIN 5008: Funktionsbezogene Trennung durch Leerzeichen, Durchwahl mit Bindestrich abgetrennt.






    +49 30 1234567

    E.123: Durchwahl nicht gekennzeichnet.






    +49 (30) 12345 - 67

    Microsoft:[6] Ortsnetzkennzahl eingeklammert, keine Vorgaben zur Unterteilung von Teilnehmernummer und Durchwahl, dennoch wird die Durchwahl mit Bindestrich abgetrennt.






    tel: +49-30-1234567

    Uniform Resource Identifier nach RFC 3966; wie E.123, jedoch mit Bindestrich statt Leerzeichen






    +49 (0)30 12345-67

    In Deutschland und Österreich verbreitete,[2] aber nicht standardkonforme Schreibweise: Verkehrsausscheidungsziffer 0 wird in Klammern eingefügt. Bei der automatischen Rufnummernerkennung z. B. mobiler Geräte kann es zu Fehlern kommen, da die Nummer wegen der eingeschobenen Null ungültig und eine Anwahl deshalb nicht möglich ist.






    Rufnummer – Wikipedia
    de.wikipedia.org


    Auch noch interessant:


    Klickbare Telefonnummern - beispielsweise in E-Mails (siehe meine Rufnummern unten) oder auf Internetseiten:


    HTML/Tutorials/Links/klickbare Telefonnummern – SELFHTML-Wiki


    Also beispielsweise tel:02211234567 oder tel:00492211234567.

    Viele Grüße


    d i r k

    Quote from roady1969

    Bist du Vater? :/

    Deshalb.

    :D :D :D

    ^^ ok, das lass ich gelten ^^


    Um aber die Lösung für das Problem noch einmal in den Vordergrund zu stellen:


    Man nehme ein estos MetaDirectory, binde seine verschiedenen Datenquellen mit den wüstesten Formatierungen an und läßt das MetaDirectory das beim Import normieren :) Die STARFACE kann dann eine zuverlässige Rufnummernauflösung gegen das MetaDirectory als LDAP-Quelle durchführen.


    Das ist dann die Zwischenschicht, die ich angesprochen hatte.

    Danke für Eure ganzen Beiträge. Ich verstehe das technisch alles. STARFACE sollte sich hier meiner Meinung nach aber die Anwenderbrille aufsetzen. Es kann nicht sichergestellt werden, dass der Anwender immer daran denkt, wie er eine Rufnummer eingeben muss, damit es richtig aufgelöst wird. Zumal das andere Systeme einfach so können. Für uns ist es "einfach", weil wir die Daten beim Export in das gewünschte Format bringen. Aber "richtig" aus Anwendersicht ist es meiner Meinung nach nicht und die STARFACE könnte hier locker mal beim Import eine Normierung durchführen. Andere können bzw. machen das auch. Ein MetaDirectory verkaufen, nur weil STARFACE das nicht kann ist für mich keine Lösung. Halte ich für überzogen :) Zumal unser DMS per TAPI angebunden ist und die Rufnummer auch richtig anzeigen kann - egal wie diese geschrieben ist. Sogar wenn noch Text dahinter steht. Es ist hier einfach ein "Problem" der STARFACE.


    Wie würde ich diesen Sachverhalt jetzt denn an die STARFACE kommunizieren? Also über welchen Kanal? Hier im Forum jemanden markieren? Oder ganz normal an den Support schreiben?

    • Official Post

    Hallo Patrick,

    Quote from Patrick.Fischer

    Wie würde ich diesen Sachverhalt jetzt denn an die STARFACE kommunizieren? Also über welchen Kanal? Hier im Forum jemanden markieren? Oder ganz normal an den Support schreiben?

    das Thema habe ich aufgegriffen ;) ich kümmere mich um eine STARFACE Aussage


    Grüße

    @roady1969:


    Eine Frage wäre aber auch, ob das mit der Suche im Adressbuch bei einer HyperV...e aus Bielefeld bei 1.000 Nebenstellen wirklich gut und problemlos klappt...


    Wenn Du so etwas im Einsatz hast in der Dimension, dann schreib doch einfach mal "ja".


    Ok, ich sehe gerade, funktioniert ja nur bis 250 Nutzer... :)


    Ich selber bin froh, dass ich da mehr oder weniger weg bin (ist auch eine Kostenfrage, wenn dort alle im Forum schreiben STAR...E sei teuer, dann ist das relativ und zielgruppenabhängig. Wenn ich 100 Systemtelefone kaufen muss ist das genau umgekehrt. Ich habe früher nur die AS200IT vermietet, was kleineres war mir zu unflexibel.


    Es kommt ja noch auf andere Sachen an, ich lasse vom Distributor Telefone zum Kunden schicken und die konfigurieren sich automatisch. Mit kundenspezifischen oder TV-spezifischen Hintergrundlogo.

    Viele Grüße


    d i r k

    Edited 4 times, last by d i r k ().

    AS ist sehr lange her.

    Quote from d i r k

    Ich habe früher nur die AS200IT vermietet, was kleineres war mir zu unflexibel


    Und, naja, ein Benutzer kostet bei der HV ab 1,36 EUR auf Monatsbasis oder nur 51,- EUR als einmaliger Kaufpreis.


    Telefone dann nach Gusto.


    Und klar, Systemtelefone kosten. Aber ehrlicherweise halten die 3x länger, werden 3x länger unterstützt (nie die Gefahr, dass nach Update der Anlage die Geräte nicht mehr unterstützt werden) und haben einfach wesentlich mehr an Komfort, was sich mit Yealink und Co einfach nicht an einer SF umgesetzt bekommen läßt.


    Wir setzen daher Bielefelder Systeme dort ein, wo das gefordert ist.


    SF dann dort, wo man Spezialsachen braucht, die man mittels Modul lösen kann.


    So hat jeder seine Berechtigung.


    Wenn gleich viele unserer Kunden (mittlerweile) mehr wert auf (PC-) Telefonkomfort legen.


    Denn das SoftPhone bzw der Client ist auch ziemlich genial bei denen.


    Und nicht wirklich teuer.


    Wie gesagt, es kommt drauf an.


    Aber, ich sagte es, lassen wir es hier. Ist ein SF Forum…

    Und ich bekomme schon immer mal auf die Finger gekloppt aus Karlsruhe, wenn ich solche Aussagen treffe.

    • Official Post

    Hallo Zuammen,


    wie Anastasia Raevski angekündig hat, möchte ich Euch unserer Perspektive zu dem Thema darlegen.

    Quote from Patrick.Fischer

    Aber "richtig" aus Anwendersicht ist es meiner Meinung nach nicht und die STARFACE könnte hier locker mal beim Import eine Normierung durchführen.



    Von der SF wird in diesem Zusammenhang kein Import der Daten vorgenommen. (es sein denn, das Adressbuch wird tatsächlich in das interne Adressbuch der SF importiert)

    Die SF sendet ja nur die Anfrage zur Auflösung der Rufnummer an das externe Adressbuch.

    Auf die Antwort vom externen Adressbuch (mit oder ohne Namensauflöung) haben wir als Telefonanlage keinen Einfluss.

    Quote from Patrick.Fischer

    Es ist hier einfach ein "Problem" der STARFACE

    Wir sehen die Ursache, wie oben beschrieben, an der Quelle der Daten bzw. dem Format der Rufnummern.


    Fabian hat es schon treffend formuliert. Es bestehen zwei Möglichkeiten, die Auflösung der Rufnummer erfolgreich durchzuführen:

    1. Quelle (das externe Telefonbuch) normieren. Also alle Einträge im Format +49123..bzw. 0049123.. zu speichern.
    2. Das estos MetaDirectory als “Zwischenschicht” einsetzen, um die Rufnummern, aus welchem Format auch immer, in die unter Punkt 1. geschilderten Formate zu konvertieren und somit auch die Namensauflösung aller Rufnummern zu gewährleisten.

    Beste Grüße

    Daniel

    Danke Daniel, aber wir haben die kompletten Adressen in ein Telefonbuch der STARFACE importiert. Es ist kein externes Adressbuch angebunden.

    Und von daher sollte es doch egal sein, in welchem Format die Telefonnummer im STARFACE eigenen Telefonbuch steht, oder? Macht ja auch keine Unterschied, ob ich die Daten importiere oder manuell eingebe. Ich beziehe mich hier gerne noch einmal auf meinen Eingangspost:


    Folgende Varianten können im Telefonbuch gepflegt sein. Je nachdem, wie es der Benutzer eingibt oder vom vorhergehende System geliefert wird.

    1. 0170xxx

    2. 0049170xxx

    3. +49170xxx


    Am Yealink T46S und auch am Webclient und Softphone wird der Name aus dem Telefonbuch nur korrekt aufgelöst, wenn die Telefonnummer im Format 3 gepflegt ist.

    Müsste bei Dir doch genauso sein, oder?

    • Official Post

    Hallo Patrick.Fischer,


    wir haben seit der SF 6.4.x.x einen "Rufnummer-Converter" für das Anlegen von Adressbucheinträgen und für den .csv Import implementiert.

    Dieser konvertiert alle Rufnummern auf das +49xx Format und sichert somit die Namensauflösung.


    Es gibt allerdings zwei Außnahmen:

    1. wenn die Rufnummer der Adressbucheinträge nach dem Anlegen geändert werden (dann akzeptiert die Eingabe jedes Nummernformat)
    2. Bestands-Daten aus Adressbüchern, die in SF < 6.4.x.x angelegt wurden und auf neuere Versionen upgedatet wurden.

    Trifft eine der beiden Ausnahmen bei deiner SF zu?


    Beste Grüße

    Daniel

    Hallo Daniel,


    wir nutzen die V8 in der Cloud. Unsere Daten kommen aus unserem DMS und werden über die API in ein eigenes Telefonbuch geschrieben. Ich vermute, dass es mit dem 8er Client zusammenhängt, der alle Rufnummern mit 0049 anzeigt und sich nicht nach der Einstellung in der PBX richtet. Ich würde also 1 und 2 verneinen.


    Viele Grüße

    Patrick

    Hallo Daniel,


    wir haben auf die V8 migriert und nichts am SF Adressbuch verändert.


    In der Rufliste werden die Rufnummern mit 0049 angezeigt und im Adressbuch stehen sie mit +49 drin, somit keine Namensauflösung im Client (übrigens in keinem der von mir verwendeten Clients Windows, Android, IOS).


    Vor dem Upgrade auf V8 hat alles wunderbar funktioniert, jetzt nicht mehr.


    Also müssst ihr ja etwas daran verändert haben.


    kannst du das bitte als To-Do für die entwicklung mit aufnehmen?


    Vielen Dank


    Matthias

    • Official Post

    Hallo Matthias,


    ich habe dazu bereits ein Ticket an die Entwicklung addresssiert.


    Beste Grüße

    Daniel

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login