Nach mehrfachen Wünschen soll Auerswald das LCR wieder in ein SoftLCR ( Manuelles LCR) ändern.
Auch von uns wurde es schon an Auerswald weitergegeben.
Da eine Umfrage zu diesem Thema gewünscht wurde, bitte ich mal um rege Teilnahme.
Hallo Torsten,
super, dass Du meine Anregung gleich umgesetzt hast (hatte es selbst schon versucht, doch fehlt mir dazu entweder dei Berechtigung oder ich hab´s nicht geblickt wie geht).
Ich hoffe ebenso auf rege Beteiligung, dass bei entsprechendem Ergebnis auch die Cremlinger von der Dringlichkeit überzeugt sind und dem entsprechend alles daran setzen um wieder ein vernüftiges LCR bereit zu stellen, wobei ich mich persönlich schon über eine abgespeckte “Beta-Version” vorab freuen würde.
Gruß
Alexander
Hallo Alexander,
gern geschehen.
schaut auch mal hier rein, da gibt´s noch was wie ich denke interessantes für AFH´s zu voten
http://community.jacotec.de/showthread.php?t=2560
Alexander
Hallo Zusammen,
gestern ging entsprechende mail mit der vorläufigen Abstimmung schon mal an AW.
Mal sehen,was kommt.
Hi,
wenn ihr trotz Flatrates LCR nutzen wollt, beschreibt doch mal Szenarien.
Vielleicht gibt es ja andere Lösungen! 
Hi Olli,
das ist doch kein Problem. Wie bei der alten Basic ließ sich Pro Strecke ( City, regional,International, Mobilfunk etc.) ein anderer Carrier einstellen.
Z.Beispiel:Bei den neuen Flatrates wird dieses um so wichtiger. Für City und Deutschland wird kein anderer Carrier mehr benötigt, das u.a. die Flatrate greift.Für Mobilfunk und das Ausland ist es schon wichtig dieses LCR nutzen zu können.
Die T-Com biete die Festnetzflat ( City,Deutschland ) an, dafür fällt aber Mobilfunk und Ausland nicht mit rein.Und bei diesen Beiden schlägt Sie richtig zu.
Bei den kleineren Anlagen bzw. der alten Basic ist das anpassen überhaupt kein Problem.
Das LCR ist bei der BASIC.2 und BUSINESS viel zu star.
Das Problem hatte thomasB schon mitte des Jahres mal angesprochen.Und es gab bis jetzt auch keine Lösung, außer das LCR abzuschalten und wieder manuell bei MoBIFU und Ausland selber vorzuwählen.
ODER hast Du eine Lösung??
…noch nicht einmal das manuelle Wählen der CBC-Nummer mit anschließender Wahl der TLN-Nummer ist mit der Basic.2 mehr möglich, denn sonst hätte ,man ja wenigstens übergangshalber die Provider auf eine Taste legen können und aus dem Telefonbuch wählen.
Ich kann dem zuvor geschriebenen nur zustimmen, außerdem hat nicht jeder eine Flatrate, da diese auf dem Lande z.B. doppelt so teuer ist, wie in der City. Gerade bei Auslandsgesprächen und Mobilfunkteilnehmern ist ein editierbares LCR ein Pflicht.
Wenn ich mit dem LCR-Easy und dessen besch…eidenen Tarifupdates z.B. nach Thailand / Mobilfunk rufe kostet mich das im Moment gerade mal 1,9 ct (01035), mit dem Update aber ca. 6,2 ct je Minute, was Faktor 3 bedeutet, und dafür hat man auch noch Update-Gebühren zu zahlen.
Das Argument, es werden eben stabile, gut verfügbare Anbieter ausgesucht, zählt für mich auch nicht, denn wie oft habe ich nun (auf dem Land) einen Rückfall zur T-Com, was bei meiner manuellen Konfiguration höchsten 5% der Anrufe betraf. Ich denke man macht es sich bei den Update-Recherchen zu einfach. Wenn schon, dann sollte jede Landesvorwahl + Mobilfunk für jedes Land der Welt und unter Berücksichtigung nur regional verfügbarer Anbieter tarifoptimiert werden, was natürlich unheimlich arbeit macht.
Einige Firmen haben ausserdem kostengünstige Verträge mit Providern um gezielt firmeneigene Nummern z.B. im Ausland oder via Mobilfunk (z.B. EPlus-Company-Call oder sowas in der Art) anzuwählen, was mit der Basic.2 im derzeitigen Stand nun nicht mehr automatisch möglich ist.
Ich denke das sollten doch ausreichend Szenarien sein…
Um das alles zu umgehen, ist es einfach Pflicht ein editierbares LCR zur Verfügung zu stellen, was von mir aus ja auch über eine automatische Updatefunktion verfügen könnte, aber eben editierbar.
Ich denke im derzeitigen Stand, insbesondere in Bezug auf das LCR ist die Basic.2 nur bedingt verkaufbar, was letztendlich ja die Fachhändler entscheiden, denn eben diese bestimmen das Geschäft !
Was der Fachhändler nicht anbietet, kann der Kunde nicht kaufen - Auerswald sollte wirklich schnellstens was bez. dem LCR auf die Beine bringen,
Gruß Alex
Hi,
Eure Beschreibungen gehen mir persönlich nicht weit genug. Mehr Details Jungs.
Im Grunde würde nach Euren Beschreibungen das manuelle LCR der Basic 1 / COMpacten ja ausreichen.
Was mir da aber noch fehlt, ist die gezielte Auswahl eines Ports. Immerhn hat man beim Basic.2/Business das LCR nicht nur für die internen Teilnehmer einstellbar gemacht, sondern auch pro S0-Port. So kann ich wenigstens S0-Ports vom LCR ausnehmen (z. B. bei Flatrates).
Über das VoIP-/GSM-Routing kann ich dann gezielt Gassen auf die entsprechenden Ports routen.
Das ist schon mal ganz nett. Aber die Ausnahmerufnummern des VoIP-/GSM-Routings kann man nicht zeitgesteuert ändern.
Letztendlich fehlt natürlich die manuelle Eingabemöglichkeit der Tarife. Aber wie will man das vernünftig verheiraten? Auf der einen Seite möchte ich eigentlich das VoIP-/GSM-Routing in die Tabellen integriert haben, dann muss ich aber bei Anlagen, die nur das VoIP-/GSM-Routing nutzen das LCR einrichten, obwohl es nicht notwendig ist.
Kurzum, das manuelle LCR der COMpacten ist ein wenig angestaubt und darf so eigentlich nicht in die Basic.2 / Business übernommen werden.
Was steht noch auf meiner Wunschliste?
Ach ja, Providerazeige im Display oder das Einpflegen der Minutenpreise pro Provider und Tarifzone etc…
Hallo Olli, hallo Zusammen,
ich wäre schon glücklich wieder mit dem alten LCR + VoiP-Routing arbeiten zu können, denn wie schon erwähnt, traue ich mich im Moment nicht die Basic.2 anzubieten.
Obwohl die Anlage sehr viele Verbesserungen birgt, ist das LCR-Easy ein Rückschritt höchster Güte !
Aber gut – wenn schon, denn schon Zusammenführung des Ausnahme-Routings und LCR !
Da es wohl nicht möglich ist im Forum eine Art Liste zum übersichtlichen Eintrag aller Ideen, Wünsche und Fehlerbehebungsmassnahmen zu generieren (oder doch ?) versuche ich halt so mal zusammen zu tragen was mir zum LCR für die Basic.2 so einfällt, wobei ich mich immer und immer wieder frage, warum so ein Brainstorming nicht schon vor der Entwicklung bei den AFH´s abgefragt wurde, bez. falls das geschehen ist, wie so etwas dabei heraus kommen konnte.
Mein „Brainstorming“ zu LCR / Routing :
-
manuelles Editieren der Anbieter, Zeiten etc.
-
LCR und Routing in einer Anwendung zusammen führen (ist
übersichtlicher als viele Anwendungen die sich gegenseitig beeinflussen können) -
Haupt/Rückfall-CbC-Anbieter (keine Trennung mehr zwischen Haupt-und Rückfallanbieter),VoiP-Zugänge, GSM-Zugänge gleichberechtigt in einem Pull-Down-Menue für jedes Ziel bzw. Gruppe (z.B. wie beim alten LCR :Ort, Fern, 0171, 0176) und jeder Tageszeit zur Auswahl stellen (so kann für die jeweilige Situation alles exakt konfiguriert)
-
Integration des Kalenders zur Übernahme von Feiertagen
-
Rückfall auf den Netzbetreiber abschaltbar gestalten (z.B. für die Wahl via Call-Through ins Ausland unerläßlich, da andernfalls Kostenfalle)
-
Manuelles CbC und Nachwahl aus dem Telefonbuch
-
Zeit-, Wochentags -und übergeordnet Konfigurations-steuerung des Routings
-
Separate Einstellung für alle Ämter (einzelne Wochentage zu Mo-Fr zusammenfassbar)
-
Berücksichtigung von Verbindungszeiten um z.B. Freiminuten und anschließend das Routing nutzen zu können
-
Alle Eingaben für jeden Zugang (Amt, VoiPm, GSM) separat zur Verfügung stellen um Flatrates nutzen zu können.
Bei folgendem „Szenario“, welches ich genau so als Aufgabenstellung habe, könnte so alles optimal abgedeckt werden :
Der Kunde hat einen Anlagenanschluß mit 2 Ämtern ohne Festnetzflat, 2 VoiP-Zugänge bei unterschiedlichen Anbietern mit x Freiminuten zu bestimmten Zielen im Ausland (z.Zt. VoipDiscount + Sipgate-Basic mit 01801-er Nummer), sowie ein GSM-Modul um u.a. Mitarbeiter-Telefone in den Fahrzeugen im gleichen Netz kostenlos anzurufen (über Eplus).
Außerdem gibt’s viele Geschäftspartner o.ä. im Ausland, zu denen auch die Mitarbeiter in den Fahrzeugen via CallThrough über das LCR kostengünstig oder falls noch Freiminuten des VoiP-Zuganges zur Verfügung stehen über diesen Zugang anrufen sollen ohne aber über den teuren Netzbetreiber verbunden zu werden.
Dem nicht genug hat der Kunde je ein Buchhaltungs-Büro im Inland als auch im angrenzenden Ausland (Heimarbeitsplätze) mit einer AWS von Büro im Inland an das Büro im Ausland, wobei z.B. bei nicht zur Verfügung stehender VoiP-Verbindung das Festnetz, aber ausschließlich via LCR ohne Rückfall auf den Netzbetreiber benutzt werden soll.
An Wochenden und an Feiertagen, sowie außerhalb der Geschäftszeiten soll keine AWS stattfinden, sondern ein AB (VMC 461) im Büro im Inland anspringen, welcher je nach angewählter Durchwahl verschiedene Texte abspielt und die Nachrichten auch in verschiedenen Boxen ablegt (das geht mit der Basic.2 ja nun auch nicht mehr).
Bei der „Hotline“-Box werden die Anrufe ggf. an einen Außendienstmitarbeiter weitergeleitet, dessen Mobiltelefonnummer deshalb nicht extern bekannt geben wird, da sich 3 Mitarbeiter abwechseln und je nach gewählter Konfiguration eine der dafür eingerichteten 3 Gruppen die lediglich zur AWS dienen, an das jeweilige Mobiltelefon verbinden.
Das ganze hört sich vielleicht recht „exotisch“ an, ist es aber nicht – es ist ein realer Fall.
Ich hoffe das „Szenario“ ist nun ausreichend komplex.
Sollte es hierfür eine andere Möglichkeit als die oben vorgeschlagene geben, bin ich ganz Ohr - je einfacher, flexibler und übersichtlicher das ganze ist, desto besser.
Gruß Alex
@ Olli :
Kann es sein, dass wir uns persönlich kennen und vor dem Urlaub vor ca. 4 Wochen nach langer Zeit mal wieder miteinander telefoniert haben ?
Hallo Olli,
im Grunde genommen sehe ich kein Hindernis, das manuelle LCR natürlich unter Berücksichtigung des Ausnahmeroutings für VoIP und GSM zu implementieren.
Die Bedingungen, wann das Routing greift, und für welchen S0 es gilt, bleiben selbstverständlich so erhalten, wie sie sind. Das ist ja im Moment auch so, d.h. es wird geprüft, ob für diesen Port LCR oder GSM gilt, ob die Nummer im VoIP-Routing steht - und dann wird das Ganze ans LCR “weitergereicht”. Nur das das LCR dann endlich etwas Vernünftiges ist, und nicht dieses Krüppelzeugs von Easy-Least-Cost-Quatsch.
Was haben wir gekämpft, gebettelt und gebeten - seinerzeit für die COMpact 2206 und 4410 dem Schwachsinn eine richtige Alternative zu geben. Es war ein endloser Kampf, und nach Drängen etlicher Leute hat man es dann eingabaut. Aber was hat man daraus gelernt? Nichts! Beim Business und Basic.2 - ausgerechnet in der “Profiliga” - wieder der gleiche Fehler, ein Möchtegern-LCR, über den sich Familie Huber mit 2 Nebenstellen nach Verwendung des Easy-Setup-Programms für Normalsterbliche sicherlich freut. Aber z.B. in einer Anlage, die 3 Tage Seminar erfordert, um sie in Betrieb nehmen zu können, da kann man doch dem Errichter auch zutrauen, ein LCR so zu programmieren, wie es der Kunde haben will? Man kann die Kinderkacke da ja drinlassen, hat ja keiner was gegen - wer damit glücklich ist: Bitte schön.
Das Thema kommt mir nach jahrelangem Bitten und Betteln nach einem LCR “für Erwachsene” gerade recht … mein Baby zickt gerade mal wieder so richtig mit diesem Schrott rum und ich habe das Ganze gerade schon per Mail an Uwe und Friedrich geschickt.
Der Einzige, der die Kontrolle über mein LCR haben soll, bin ich - und nicht irgendeine Pseudo-Intelligenz die von Zeit zu Zeit sogar die Einstellungen vergisst und der man neuerdings nicht mal mehr beibringen kann, dass die Telekom der Netzbetreiber ist 
Im Moment routet das Teil nämlich eben deshalb mal wieder wie es will, und ich überlege ernsthaft, neben die Telefone wieder Zettelchen zu hängen, für welches Ziel man nämlich welche Vorwahl manuell davorsetzen muss. Oder vielleicht machen wir hier einen Forums-Sammelkauf alter Hicom’s bei eBay, die wir dann als LCR-Router vor unsere Business / Basic.2 schalten. Die konnten es nämlich vor 10 Jahren schon vernünftig, als so richtig noch keiner Call-by-Call kannte.
[b]Raus endlich, mit dem blöden Quatsch!
[/b]LG
Marco
Das ist eben der falsche Weg. Wenn schon implementieren, dann bitte richtig!
Ein LCR muss alle Leitungswege berücksichtigen können und nicht mit Hilfe einer statischen, zeitunabhängigen Vorauswahl (Ausnahmerouting) zunächst ein paar Fälle erledigen lassen, um dann noch ein paar CbC-Vorwahlen zu wählen. Ein LCR muss die Kosten für alle Leitungswege in Betracht ziehen.
Die Tatsache, daß VoIP- oder GSM-Gateways vorhanden sind bzw. Amtsanschlüsse mit verschiedenen Kostenstrukturen bestehen oder es externe S0 mit Kopplungen zu anderen (internen) Tk-Anlagen gibt, wird derzeit überhaupt nicht sinnvoll berücksichtigt.
Ein LCR muss daher zu einer gegebenen Rufnummer ein Tupel aus <Leitungsweg; Präfix> generieren, wobei Leitungswege ja auch Klassen von Leitungswegen sein könnten (z.B. alle GSM-Gateways oder alle VoIP-Gateways).
Das wäre aus meiner Sicht die Mindestanforderung an ein sinnvolles LCR, das mit Hilfe einer automatisierbaren Updatefunktion aus einer selbst erstellten Tabelle (oder einer z.B. von www.telefonsparbuch.de ) aktualisiert werden kann. Wie soll ein externer Dienstleister meine VoIP-Konfiguration kennen?
Weiter denkend (und hier unterstelle ich Auerswald mal einen Wunsch nach Innovation, die aber nur Innovation bezogen auf ihre eigenen Produkte wäre, nicht auf die am Markt verfügbaren) sollte man eigentlich erwarten, daß auch ein Rewriting von Rufnummern möglich sein sollte… z.B. um externe Anlagen, die per VoIP angekoppelt sind, als virtuelle Nebenstellennummern mit zu integrieren… oder für VoIP-Gateways spezielle Rewrites durchzuführen. Das muss nicht gleich die Mächtigkeit von Asterisk haben, aber zumindest ein paar Präfix-Regeln mit Matching/Replacement wären sehr hilfreich.
IMHO verstellt sich Auerswald selbst einen Teil des Marktes, da solche Routingfunktionen einfach fehlen. Diese zu implementieren kann jedoch keine Hexerei sein… selbst in der COMmander Basic (V1). Einfach LCR und Ausnahmerouting sinnvoll zusammenführen…
–gandalf.
[quote=Marco]Hallo Olli,
Raus endlich, mit dem blöden Quatsch!
LG
Marco[/quote]
So deutlich wie Marco wollte ich mich nicht ausdrücken, trifft die Sache aber auf den Punkt - hatte ja schon zu Beginn der ganzen Diskussion über das LCR bemerkt, dass das ganze die Programmierzeit nicht wert ist.
Bei der manuellen “LCR-Variante” mit Zettelchen auf Telefon kleben, bitte nicht vergessen, dass so die Nachwahl aus dem Telefonbuch auch nicht mehr geht ! Lediglich ein gezielter “Amts”-Zugang bzw. über VoiP funktioniert auch mit Nachwahl aus dem Telefonbuch, d.h. alles andere ist wieder von Hand einzutippen - bin mal gespannt, ob wir dann bei der Basic.3 wieder auf Wählscheibe umsteigen müssen - o.k., war jetzt böse und sollte nur ein Joke sein 
.
Bez. der LCR-0900-er-Updatefunktion kann ich all dem auch nur immer wieder zustimmen ! Mir kommt das teilweise so vor, als ob da einer in der Mittagspause die Bildzeitung ließt und so nebenbei die dort aufgeführten wohl günstigsten Tarife im Raster 08-12 Uhr, 12-20 Uhr und 20-08 Uhr unter Berücksichtigung Ort, Nicht-Ort, Mobil-Telefon allgemein und Ausland allgemein mal schnell eintippt, denn mehr kann es bei den üblen Tarifen deren Provider dann auch noch ständig einen Rückfall generieren eigentlich nicht sein - die Vermutung liegt dabei nicht fern, das diese Updates nicht nur durch die Einwahlgebühren der Kunden finanziert werden…
Wäre mal interessant so eine von mir aus ja 2 Wochen alte LCR-Tabelle hier einsehen zu können.
Kann nur immer wieder sagen schade, schade, schade, dass eine im Grundsatz gute Anlage durch dieses “Beiwerk” alles andere als geschmückt wird.
Ich hoffe bei dieser Diskussion handelt es sich in Bezug auf die Cremlinger “nur” noch um das “wie” bzw. “wann” und nicht um das “ob” - eine entsprechende Verlautbarung auf der Homepage, wäre z.B. als Verkaufsargument doch recht hilfreich.
Gruß Alex
Hi Jungs,
na das nenne ich mal Brainstorming.
Ich denke, das unser Lieblings-Tk-Anlagen-Hersteller den Ruf des Marktes sehr deutlich vernehmen wird. Nicht zuletzt durch dieses Forum.
Man wird in Schandelah nicht mehr beliebig lange mit einer Implementation eines manuellen und modernen LCRs warten können.
@Alex: Ich habe mir die Option mit den Volumentarifen (Freiminuten) mal skizziert. Dabei müssen reichlich Parameter des Kunden pro “Volumen-Provider” abgefragt werden:
- Das Volumen als Solches (z. B. 120 Minuten)
- Berchtigte Zonen des Volumentarifes (z. B. nur nationales Festnetz)
- Die Taktung und zwar des 1. Taktes und die Folgetakte (z. B. 1/1 oder 60/10 oder …)
- Abrechnungszeitraum (ab wann beginnt es neu zu zählen)
- Ist eine Zwangstrennung bei Ablauf des Volumens gewünscht (ja/nein)?
- Sperrung des Providers/Accounts nach Ablauf des Volumens bis zum nächsten Abrechnungszeitraumes
- Steht der Tarif auf jedem Port zur Verfügung?
Diese Parameter sind mir mal schnell eingefallen. Da fehlt sicherlich noch das eine oder andere. Ich kann mir auch nicht vorstellen, das einige von den aufgezählten Parametern fehlen dürfen. Bei einem Volumentarif kommt es ja auf eine sehr genaue Berechnung an, da ich ja nicht eine Minute verschenken möchte.
Die Idee finde ich geil. Trotzdem finde ich das schon echt heftig und nur von wenigen Kunden nutzbar (Schwierigkeitsgrad).
Ach so, die Frage mit dem Urlaub. Ich glaube wir kennen uns nicht.
Mensch da kommt ja richtig Freude auf.
So direkt wie Marco hätte ich das auch nicht ausgedrückt, aber es trifft den Nagel auf den Kopf.
Das Brainstorming dürfte dürfte doch nun für Auerswald fast komplett sein.
Also Auerswald, Termin-WANN???
Die Zeit drängt…
Hallo Zusammen,
wie schon gesagt, waren meine “Ergüsse” bez. LCR / Routing nur ein grobes Brainstorming ohne Anspruch auf Vollständigkeit und sicher habe ich dabei potentielle mit unbekannten Faktoren behaftete Punkte wie z.B. den Abrechnungszeitraum nicht berücksichtigt.
Auch sehe ich ein, dass das eine oder andere aufgrund des sehr,sehr großen Aufwandes wohl nicht umsetzbar sein wird, doch wäre es nicht schlecht dem relativ nahe zu kommen und zumindest die benötigten Funktionen wie auch immer abzudecken um die Basic.2 auch in Bezug auf das LCR in diese Anlagen-Klasse zu bekommen.
Da wäre nun nur noch eines :
Ich gehe zwar davon aus, dass hier im Forum auch Auerswald-Entwickler bzw. Produktmanager aktiv sind und somit der Informationsfluß gewährleistet ist, doch ist dem auch wirklich so ?
Also alle Auerswald-Mitarbeiter bitte mal laut geben :pepper: :party: 
Oder ist´s nötig per E-Mail einen Link hierher zu schicken ?
Gruß Alex
P.S.:
Nachdem ich hier erst 4 Wochen angemeldet bin, aber schon in vielen Foren zu allen möglichen Themen aktiv war und diese Aktivitäten deshalb abgebrochen habe, weil sich die Teilnehmer ständig angegiftet haben, d.h. keine sachliche Diskussion führen konnten, bin ich umso glücklicher darüber, dass es hier fair und kollegial zu geht !
Hoffe nur, dass wir damit auch wirklich was bewirken können.
Naja … ich habe es vielleicht etwas deutlich ausgedrückt, aber ich hatte gestern wiklich mal wieder Frust gehabt. Und das Thema beschäftigt mich wie gesagt ja nicht erst seit gestern. 
Natürlich würde ich mich auch über ein noch leistungsfähigeres LCR freuen, vielleicht noch mit Verzonung und Gebührendatenerzeugung … aber das ist natürlich - vor allem, wenn es bündelabhängig ist - auch nicht unaufwendig. Daher wäre ich ja schon froh, wenn es erstmal ein LCR wie im Basic.1 gäbe, damit man es wenigstens mal vernünftig verwenden könnte. Lieber so etwas schnell, als was “Großes” erst in einem halben Jahr oder mehr…
@Alex: Gehe davon aus, dass unser Lieblings-TK-Hersteller hier mitliest oder gar aktiv ist. Aber gehe auch davon aus, dass die entsprechenden Leute sich nicht outen werden, schließlich ist das hier kein wirklich offizielles Herstellerforum (auch wenn gerne in Auerswald-Kreisen mal darauf hingewiesen wird).
Und: Ja, der Umgangston hier ist erfreulich gut. Liegt mir auch viel daran!
LG
Marco
Viele der LCR-Themen sind recht einfach zu behandeln, wenn man sich mit der Idee virtueller Anbietervorwahlen befasst.
Bei Volumentarifen gäbe es dann z.B. eine Anbietervorwahl, die nach Aufbrauchen des Volumens für eine bestimmte Zeit gesperrt bliebe. Damit kann man die Varianten “im Freivolumen” und “im Normaltarif” sehr einfach durch zwei unterschiedliche Tarife mit unterschiedlichen Vorwahlen repräsentieren. Die meisten Volumentarife, die auf festen Zeitgrenzen arbeiten (z.B. Monaten), lassen sich damit behandeln. Betamax-Volumentarife mit Freedays und max. Gesprächsvolumen in gleitenden 7-Tages-Intervallen sind natürlich komplexer… aber das will man ggf. auch nicht abbilden.
Virtuelle Anbietervorwahlen könnten auch zur Auswahl von VoIP- oder GSM-Leitungswegen in nachgeschalteten Gateways genutzt werden (entsprechend #12x* in der Fritz!Box Fon). Weiterer Vorteil: man könnte diese Vorwahlen wie andere an Telefonen der Anlage auch manuell wählen.
Anbietervorwahlen hätten dann eine “Amtsgültigkeit” bzw. auch ggf. “Vorzugsämter”, so daß eine Priorisierung bzw. der Ausschluss von ext. Kanälen stattfinden kann.
Vor Übergabe eines Tupels <Anbietervorwahl, Rufnummer> an einen externen Kanal würde eine Umsetzung stattfinden, um die tatsächlich zu wählende Nummer zu bestimmen. Das könnte mit Hilfe von einfachen Matching/Replacement-Regeln für Nummernpräfixe erfolgen, um zumindest etwas mehr Gewalt über die Nummern zu bekommen.
Die Mechanismen, um ein solches LCR umzusetzen, wären sogar in der Basic.1 im Prinzip vorhanden… wenn man mal die ggf. speicherbedürftige Volumentariflösung ignoriert, könnte das doch in den begrenzten Speicher selbst der Basic.1 passen Wie wäre es mit einer Firmware-Version 3.0A? 
Ach ja, und bei der Gelegenheit fällt mir natürlich noch der Wunsch nach ENUM-Unterstützung in der Basic.2 ein Wenn schon VoIP, dann richtig! …wobei ENUM-Lookups eigentlich vor Anwendung eines LCR stattfinden sollten, da ein ENUM-Lookup ja auch eine Festnetznummer (auch 0900) liefern könnte.
–gandalf.
Ups - Gandalf, scheinst ja bis zum Hals in diesem Thema zu stecken.
Komme da offen gesagt vom Know-How her nicht ganz mit, hört sich aber gut an :good: .
Bis auf die letzte Millisenkunde, denke braucht das Routing ja auch nicht ausgereizt zu werden, auch wird es wohl nicht sehr sinnvoll sein, sich so exotische Abrechnungsmethoden wie bei Betamax anzupassen, denn diese können sich ja ganz schnell ändern.
Eventuell wäre ja auch eine prozentuale Verteilung der Verbindungen auf die einzelnen Anbieter / Ämter oder wie auch immer ausreichend um z.B. Freiminuten annähernd optimal auszunutzen und anschließend ggf. LCR zu verwenden (z.B. 70% VoipDiscount, 30% LCR natürlich nur wenn für betr. Ziel kein bestimmter Weg vorgegeben worden ist).
Den Nutzungsgrad kann der Einrichter / Betreiber ja ganz einfach und schnell sehen und die Verteilung dann entsprechend anpassen.
Mir wäre als schnelle Übergangslösung auch schon mal die einfache Implementierung des LCR von der Basic.1 willkommen - eine völlig neue und hoffentlich dann an die Kundenbedürfnisse angepaßte Lösung würde sich dann zur nächsten CeBit anbieten.
Ich habe zwar nicht den Einblick wie aufwändig die Implementierung des LCR von der Basic.1 in die Basic.2 ist, doch denke ich, dass das als “schnelle” Lösung doch realistischer ist, als eine komplett neue LCR-Version.
Wir sollten den Entwicklern also schon die nötige Zeit zugestehen, benötigen aber wohl alle eine wie auch immer gestaltete, schnelle Lösung um in Bezug auf LCR / Routing zumindest so wie mit der Basic.1 arbeiten zu können, was keinesfalls bis zur CeBit dauern darf.
Da sollte sich noch was in 2006 bewegen - oder sieht das jemand anders ?
(Schaut mal hier - da gibt es wieder was zu Voten :
http://community.jacotec.de/showthread.php?t=2586 )
Ich denke es wäre wichtig in Bezug auf unsere LCR-Anforderungen und die “schnelle Lösung” eine gemeinsame Linie zu haben, damit Auerswald auch erkennen kann, was aus AFH-Sicht denn nun unbedingt und schnell benötigt wird, was wichtig wäre aber noch etwas Zeit hat (CeBit), sowie was als zusätzliches Feature, ohne welches sich aber auch leben läßt zu sehen ist, wobei sich die Entwickler sich die gleichen Fragen sicher gerade selbst stellen werden.
Gruß Alex
@ Marco:
Hatte nicht ernsthaft erwartet, dass nach meinem “Aufruf” nun alle Auerswald-MA laut “hier” rufen, aber einen Versuchs war es ja mal wert .
Hi,
ich bin mir ganz sicher, das Auerswald hier “lauscht”. Anders kann ich mir einige Implementationen nicht erklären.