@1Rainer

Du meinst "angezeigt" durch die optische oder akkustische Anrufsignalisierung von Phoner?

Wenn die teilnehmende Nebenstelle eines Anlagenanschlusses  bei nicht aktiviertem Tarifmerkmal CLIR (Calling Line Idenfication Restriction, Rufnummernunterdrückung) die eigene Rufnummer überträgt, und bei Dir das Tarifmerkmal CLIP (Calling Line Idenfication Presentation, Rufnummernanzeige) aktiviert ist, und Deine Hardware (Telefon, ISDN-Anlage etc.) die eingehende Rufnummer identifizieren kann, so handelt es sich bei der übermittelten Rufnummer immer um eine eindeutige Rufnummer.

Phoner identifiziert anhand dieser eindeutigen Rufnummern-Kennung eine gleichlautende Eintragung im Telefonbuch, und generiert anhand der Eintragung die optische oder akkustische Signalierung des anrufenden Teilnehmers.

Besteht zu einer Rufnummer kein Eintrag, so wird lediglich die Rufnummer des anrufenden Teilnehmers signalisiert.

Die Möglichkeit, sogenannte Wildcards in das Telefonbuch einzutragen (z. B. (321) 1234 ***, *** für eine beliebige Durchwahl bzw. Nebenstelle = Firma ABC) ist nicht möglich, da ein Vergleich zwischen Telefonbucheintrag und übermittelter, eindeutiger Nummer wahrscheinlich zu aufwendig wäre, wenn Teile der Telefonbuch-Rufnummer durch WildCards ersetzt wären.

Auch bei Eintragung lediglich der ersten Ziffern eines Anlagenanschlusses reagiert Phoner nicht so, als ob der anrufende Teilnehmer durch die ersten Ziffern erkannt werden könnte, da lediglich die eindeutige, übermittelte Rufnummer Ausgangspunkt für einen Vergleich mit den Telefonbucheintragungen ist.

D. h. jede Rufnummer der Art (Stadtkennzahl) Rufnummer Nebenstelle kann nur angezeigt werden, wenn genau die übermittelte Kombination einer übertragenen Rufnummer bereits im Telefonbuch steht. Das Problem bei dieser Sache ist, dass die Rufnummer beim CLIP im Format (Stadtkennzahl) Rufnummer empfangen wird, und Phoner nicht in der Lage ist, die Anzahl der jeweiligen Schlussziffern für die Nebenstelle zu erkennen - es sei denn wiederrum, sie steht in Deinem Telefonbuch. 

Mit anderen Worten: CLIP kennt kein Trennzeichen zwischen Rufnummer und Nummer der Nebenstelle. Falls es das geben würde, ließe sich leicht programmieren, dass bei einmal erkannter Nebenstelle eine beliebige Ziffernfolge (von hinten gezählt) dem Anlagenanschluss eines bestimmten Teilnehmers zuzuordnen ist.

Daher ist es egal, ob man eine Rufnummer vom Typ (Stadtkennzahl) Rufnummer Nebenstelle in das Telefonbuch auch genauso einträgt, oder lediglich als (Stadtkennzahl) Rufnummer.

Leider wirst Du wohl sämtliche Anlagenanschlüsse dieser Firma ABC in Dein Telefonbuch eintragen müssen, damit Du den gewünschten Effekt erhälst.

Grüße vom Kai

@1Rainer,

*grinsel* okay, kürzer hätt's auch getan: Ich hatte jedoch die Wahl, nach dem Essen eine Zigarette zu rauchen, oder zu texten. Du mußt wissen: Ich will mit der Qualmerei aufhören *smile*...

Sicherlich ist es einfach, eine Teilmenge eines Ganzen zu extrahieren, und dem Rest der Menge eine Bezeichnung zuzuweisen (kenn ich aus PHP, Perl, VBA, C++ etc.   ). Man nehme einen String, kürze ihn um soundsoviel Stellen (wird vom Nutzer festgelegt), und schon hat man eine ankommende Rufnummer ohne Zuweisung einer Nebenstelle, die jedoch eindeutig einem bestimmten Teilnehmer zugeordnet werden kann.

Es ist sicherlich auch relativ einfach, über den Einsatz von "Regular Expressions" bei (im Telefonbuch) gesetzten Wildcards einen solchen Teilnehmer zu identifizieren, obwohl die Kennung der einkommenden Nebenstelle dem Telefonbuch unbekannt ist.

Um jedoch zu überzeugen, solltest Du wahrscheinlich ein Essay darüber veröffentlichen, welchen Zweck diese Funktion erfüllen sollte. Ich persönlich finde, die Anrufsignalisierung anhand der Nummern, die im Telefonbuch stehen, reicht völlig aus. Nun jetzt zu wissen, ob jemand aus dieser einen Firma anruft, anstatt direkt den Gesprächspartner zu kennen (falls der Telefonbuch steht), ist meines Erachtens ohne Belang.

@1Rainer

*lol* Okay, okay, schreib' mir das nicht - schlag's dem Heiko vor. Ich habe keinerlei Einfluss darauf, was an Umsetzungen so angedacht ist.

Grundsätzlich wollen wir aber mal feststellen: Ruft Giselle an, so könnte ich DIE ja eindeutig identifizieren, weil DIE stünde ja in meinem Telefonbuch.  

Grundsätzlich gilt: Wer einen nicht identifizierbaren Anruf erhält, und sich nicht neutral meldet, ist selber schuld. Zumal der Chef der Sauna aus einer zurückgelassenen Rufnummer keinen Rechtsanspruch auf eine vereinbarte "Vergütung" herleiten kann, sonder eher aus der verabredeten Leistung... *grinsel* 

Sollte jedoch der Chef von Giselles Apparat aus anrufen, hätte man so oder so verloren.

Erfahrungsgemäß wird man bei hochnotpeinlichen telefonischen Rückfragen ohnehin die eigene Rufnummer eher unterdrücken, weil sonst der hochnotpeinlich berührte Angerufene wahrscheinlich eh' nicht abheben wird.  

Ist zwar jetzt alles theoretisch, trifft aber den Kern: Leute, deren Rufnummer man benötigt, gehören in das Telefonbuch. Alles andere nicht. Nach dem Motto KISS (Keep it simple and stupid) wäre ein solches Feature bereits mehr als dass, was Phoner zu leisten im Stande sein muß.  8)

@1Rainer

Als Delphi-Programmierer: Wie würdest Du denn den regulären Ausdruck formulieren, den Heiko für die Suche nach dem entsprechenden Telefonbucheintrag bzw. Teil-Eintrag einbauen müsste?

Dieser reguläre Ausdruck müßte - um es einfach zu halten - sowohl ganze Rufnummern finden, die im Telefonbuch stehen, als auch die Teilmenge einer Rufnummer ausgehend von einer anderen Rufnummer, deren letzte xxx-Stellen sich bereits im Telefonbuch befinden.

Vielleicht überzeugt das ja - vom programmieraufwandstechnischen her - mehr als jedwede Begründung Und wenn's Heiko hilft, und er dieser Änderung zustimmen mag, war's auch noch nicht einmal mehr verkehrt *zwinker*

Quote:


Nö. 

Aus Erfahrung: Je länger ein Thread, desto mehr Pro-Argumente für ein neues Feature, desto mehr Chancen, dass es verwirklicht wird (wenn's als sinnvoll erachtet wird).

Ich weigere mich ja nicht, Phoner zu nutzen, nur weil's ein neues Feature hat - neee, ganz im Gegenteil. Aber bei vielen Wünschen und der ganzen knappen Zeit - das kann man hier im Forum oft genug lesen - liegt nicht alles im Sinne des Erfinders, und es muss nicht alles verwirklicht werden.

Jetzt mal OT: Was machst Du denn nun genau, wenn dich Giselles Chef von Giselles Nebenstelle aus anruft? Der wird sich ja vielleicht wundern...

Heiko,

es ist simpel. 
- natürlich stehen Durchwahlen am Ende. Das liegt in der Natur der Vergabe von Rufnummern(blöcken). Eine Suche nach "(611) 12??5" macht nun wirklich wenig Sinn.
- Durchwahl-Nummern /sind/ in der Datenbank als solche erfasst (Anzeige "(611) 12345-0"). Man müsste also nur suchen, ob es einen Match der 'Rumpfnummer' "(611) 12345"gibt, wenn es vorher keinen Match einer Gesamtrufnummer gab.

Machen wir einen Deal?
Du schickst mir die Funktion die die Rufnummer sucht und ich ergänze das.


Gruss, Rainer

@1Rainer,

in einem Punkt habe ich volles Verständnis:

Im eigentlichen Telefonbuch stünde eine Nummer, die so, wie sie da steht, nicht angerufen werden kann. Der eigentliche Sinn des Telefonbucheintrages per Definition wäre - gelinde gesagt - einfach dahin.

Dir ist klar, was ein solches Feature bringen würde, Heiko wär's darüber hinaus klar (weil er's programmiert hätte), und mir ist mittlerweile auch klar, was ein solches Feature bringt. 

Jedoch:

Die Frage ist, wie beim eigentlichen Programm-Aufbau (der ja in sich logisch ist) der Endanwender in die Lage versetzt wird, eindeutig nachzuvollziehen, welche Rufnummer als Oberbegriff für einen Anlagenanschluss gesetzt wird, und welche Rufnummer eindeutig anwählbar ist.

Den Suchalgorythmus lediglich so zu verändern, dass er - laienhaft ausgedrückt - zurückgibt "des passt schon so" ist die eine Sache;

eine Routine so zu programmieren, dass der Endanwender -

(der sich ja meistens nicht mit Hilfetexten herumschlägt und auch erfahrungsgemäß nicht alle Forenbeiträge zu einem Thema durchliest)

- in der Lage ist, bewusst eine solche Funktion zu nutzen, und diese auch später von den anderen Funktionen unterscheiden kann, ist das andere Problem.

Meines Erachtens nach kann das nur damit effizient gelöst werden, indem dass Fenster, in welchem man einen Telefonbuch-Eintrag anlegen oder bearbeiten kann, um ein weiteres Text-Eingabefeld erweitert wird: "Name des Anlagenanschlusses ohne Nebenstellennummer".

Die Konsequenz dieses Vorschlages wäre also - damit es jeder direkt versteht 
- eine Umstrukturierung des Telefonbuches, 
- das Anlegen einer eindeutigen Benutzereingabe,
- die Zuverfügungstellung aller Möglichkeiten, die auch eine eindeutige Rufnummer hat (zB AB Ansage),
- eine Anpassung des Suchalgorythmus, und 
- eine zusätzliche Abfrage:

a) Suche nach "bekannten" Rufnummern im Telefonbuch, wie sie durch das CLIP mitgeteilt werden, und 

b) Suche nach "bekannten" Rufnummer-Teilen, die im Telefonbuch eindeutig dem (neuen) Feld "Name des Anlagenanschluss ohne Nebenstellennummer" zugeordnet werden können.

Ein weiteres Problem sehe ich dann darin:

Wenn Du hinter einem Anlagenanschluss zwei "bekannte" Nebenstellenpartner hast, wirst Du der Logik halber im Telefonbuch diese ebenfalls so erfassen, wie ich es oben beschrieben habe: Die Funktion zu Buchst. b) müsste auch berücksichtigen, bei einem Match ohne bekannte Nebenstellennummer den ersten gefundenen Anlagen-Teilnehmer zu melden.

Es steckt also - damit's begreiflich für jedermann wäre - mehr Arbeit dahinter als man zuerst denkt.

Eine einfachere Alternative hierzu wäre eine - automatisch zu importierende - Liste, die durch Phoner abgefragt werden müsste. In dieser Liste könnte der Anwender solche Anlagen-Anschlüsse getrennt von den Rufnummern des Telefonbuches editieren, jedoch die gleichen Möglichkeiten (AB-Ansage, Auflegen etc.) zuweisen, die eine eindeutig identifizierbare Rufnummer auch hätte. Die Abfrage bei eingehendem Anruf durchliefe zuerst das Telefonbuch (weil es ja bekannte Nebenstellen enthalten könnte...) und dann dieses "Branchenbuch".

Auch muss die Konsequenz betrachtet werden, dass bei einem ausführlichen Telefonbuch und einer zusätzlichen Abfrage der Zeitraum zwischen hereinkommenden Anruf und Anrufsignalisierung, also der Zeitraum, in welchem nach einem "Match" gesucht wird, länger dauern wird, als jetzt.

Die Räson, die hinter Phoner steckt, ist höchstwahrscheinlich der Grund dafür, dass andere Anbieter ein solches Feature auch nicht realisiert haben (PowerISDNMonitor, CallingUS etc.). Demnach sollte man sich vor Augen halten: Ist ein Feature den ganzen Aufwand wert? 

Grüße vom Kai