Verbesserungsvorschläge für LCR Berechnung

[TelefonSparbuch]

Später als eigentlich vorgesehen wird langsam das geänderte LCR Berechnungs-Modul fertig...

Da sich nun langsam diese Baustelle schließt, würde ich gerne noch Verbesserungsvorschläge aufnehmen und integrieren, ehe eine erste Testversion veröffentlicht wird und größere Änderungen problematisch sind.

Im Moment möchte ich die Option "VoIP gesondert behandeln" optimieren, da letzt endlich auch nicht alle Konstellation abgedeckt werden:

Bisher

Mögliche Lösung:

Weitere Verbesserungsvorschläge (in allen Bereichen der LCR Berechnung) können hier in diesem Thread vorgeschlagen und besprochen werden.

Ich danke Euch und Grüße
Harald

 

[andilao]

Die Sonderbehandlung von VoIP bzw. die Trennung vom Festnetz halte ich für ein Relikt mit schwindender Daseinsberechtigung. Meine Wünsche wären:

• rein kostenbezogenes Fallback: " ... immer die günstigste Wahl ..."
• aber mit strikter Kostenkontrolle: kein Fallback zulassen, wenn xx% / x,xx EUR über Erstwahl
• und unter Einbeziehung der (sehr beliebten) Betamax-Anbieter mit Abfrage von Guthaben/Freedays

Seit längerer Zeit setze ich nur noch VoIP ein und hatte in der momentenen Fassung keine Verwendung mehr für den LCR. Meine Kenntnisse über den LCR sind somit sicher veraltet und/oder lückenhaft geworden.

Zur neuen "Möglichen Lösung" für Fallback: Sieht wirklich übersichtlich und flexibel aus!
- "Erstwahl zulassen für": einer von beiden muss dann aber, sonst keine Wahl ;-)
- "Wenn ..., dann ... zulassen für": sollte es nicht "zulassen auf" sein?

 

[leo22]

Die Sonderbehandlung von VoIP bzw. die Trennung vom Festnetz halte ich für ein Relikt mit schwindender Daseinsberechtigung.

Diese Trennung ist wohl eher ein Fritz-Box-technisches Problem. Zum einen behandelt die Box Festnetz und VoIP vollkommen unterschiedlich: bei VoIP kann der LCR wählen über welche Nummer (durch Wahl des Accounts) rausgewählt werden soll; über Festnetz geht das nicht, dort wird immer die MSN der anrufenden Nebenstelle genutzt, und das kann der LCR nicht beeinflussen.

Zum anderen müssen die Fälle Festnetz gestört oder VoIP gestört berücksichtigt werden, so dass es sinnvoll ist, über den jeweils anderen Weg rauszuwählen.

Eine Berechnung des Guthabens ist ebenfalls nicht möglich. Das hat AVM einfach nicht vorgesehen.

Die vorgestellte neue Lösung von Harald gefällt mir deshalb recht gut.

 

[andilao]

Diese Trennung ist wohl eher ein Fritz-Box-technisches Problem.

Ein Frontend / der LCR muss ja nicht denselben Fehler machen und könnte einfach alles aus der Sicht eines (unbedarften) Menschen betrachten, der nur günstig telefonieren will. ;-)

Eine Berechnung des Guthabens ist ebenfalls nicht möglich. Das hat AVM einfach nicht vorgesehen.

Das ist sonnenklar, daher wäre ja ein Zugriff des LCR auf das Batamax-Account/Webinterface zum Auslesen von "Freedays remaining" eine coole Sache, denn nur für Freedays gelten die wunderschönen Betamax-0,00 aus dem LCR. Zu allem Unglück sind die günstigsten VoIP-Anbieter allesamt Prepaid-Accounts und es existiert nur eine Fallback-Ebene. So wäre die Abfrage, ob Guthaben = 0 , hier nicht ganz falsch, denn oft gibt es dann einen Fallback auf den nächsten Account ohne Guthaben (= keine Verbindung) oder auf einen sauteuren. Daher auch meine Idee der strikten Kostenkontrolle, denn ein Fallback von 0,01 EUR auf 1,00 EUR pro Minute kostet dann 59,40 EUR pro Stunde. Um dass wieder zu sparen, muss der LCR ganz schön lange ackern.

 

[leo22]

Ein Frontend / der LCR muss ja nicht denselben Fehler machen und könnte einfach alles aus der Sicht eines (unbedarften) Menschen betrachten, der nur günstig telefonieren will. ;-)

Das geht leider nicht.

Haralds Lösung basiert einzig auf dem Austausch der fc_lcr-Datei in der FRITZ!Box. Und da ist halt nur das möglich was die von AVM eingebaute LCR-Funktion hergibt. Harald nimmt ja keinerlei Änderungen an der AVM-Firmware vor, außerdem ist der AVM-LCR closed Source, so dass man hier auch gar nichts ändern könnte.

 

[andilao]

Haralds Lösung basiert einzig auf dem Austausch der fc_lcr-Datei ...

Das war mir schon klar und auch, dass der LCR beim Telefonieren keine Guthaben berechnen oder Freedays abfragen kann. Was aber hindert den LCR daran, dies beim Tarif-Update zu tun? Die Kontodaten müssten hinterlegt werden und dann könnten a) der korrekte Tarif ermittelt (0,00 bei Freedays und i.A. 1,19 ct außerhalb) und b) "leere" Konten ignoriert werden.

So würden "meine" zusätzlichen Regeln dann aussehen:

1) Kein Fallback auf "zu teure Tarife" [in % von Erstwahl oder x,xx EUR]
2) Nur Betamax: Korrekten Tarif ermitteln mit zusätzlicher Freedays-Abfrage [x]
3) Nur Betamax: Bei Erstwahl/Fallback mit Kosten ignoriere Konten mit Guthaben = 0 [x]
4) Nur Betamax: Bei Erstwahl/Fallback "kostenlos" ignoriere Konten mit Freedays = 0 [x]

Die Verzögerung bei 2) und 3) wäre dann noch akzeptabel bei max. einem Tarif-Update-Zyklus.

 

[jojo68]

Wahrscheinlich passt meine Anregung nur teilweise hierher:
Ich fände es ein tolles Feature für kommende Versionen des LCRs,
wenn bundeseinheitliche Feiertage nicht mehr von Hand eingegeben werden müssten, sondern wenn diese automatisch bei der Berechnung der Tarife berücksichtigt würden.

Ist dies möglich?