LCR: Rückfall-Probleme

Hallo,

wenn man über Amt anruft, kommen ja hin und wieder recht komische Tonfolgen aus dem Hörer, bevor das Ganze irgendwann schließlich in einem Besetztzeichen endet. Kennt Ihr sicher :o

Als noch neuer COMpact-2206-Nutzer kannte ich es nicht und kann nun auch nur schwer den Mitbenutzern nahebringen, dass das so sein muss. Inzwischen ist mir klar geworden, dass es sich um eine Mischung aus Besetzt- und Wähltönen handelt, die aufgrund des LCR-Rückfalls entsteht. Weil der angerufene Teilnehmer besetzt ist (also richtig besetzt, weil analog oder Busy-on-Busy oder einfach alle Kanäle belegt), und deshalb bis zu 3 mal gewählt wird.

Das Ganze ist nun etwas verwirrend, da man Tonfolgen hört, die zum Teil keinem der Betriebszustände (siehe “Interne Töne Probehören”) zuzuordnen sind, recht häufig aber auch durch zufällig passendes Einblenden des Wähltones ziemlich genau dem Rufton entsprechen. Ein Anrufer kommt dann schnell zum Schluss: hat 3 mal geklingelt, dann wurde mein Anruf abgewiesen. Da muss man dann erst in die Gesprächsdaten schauen, um das Rätsel zu lösen.

Ausgehend von den Beiträgen im Thema [color=blue] Compact4410USB und LCR-Fallback[/color] sieht das ja so aus, als ob es anfangs das Problem gab, dass kein Rückfall zustande kam, weil manche CbC-Provider z.B. bei Überlastung falscherweise eine Disconnect-Nachricht mit dem Parameter cause value=[color=crimson]User busy[/color] an die Telefonanlage übertragen haben.

Wenig später (Thema [color=blue]Nutzung von LCR und ISDN Leistungsmerkmalen[/color]) tritt genau das entgegengesetzte Problem auf: weil manche CbC-Provider sich falsch verhalten, verhält sich die Telefonanlage auch falsch und akzeptiert das Disconnect mit cause value=[color=crimson]User busy[/color] als Grund für einen Rückfall (neue Firmware?). Eigentlich bedeuted es aber, dass der Angerufene wirklich besetzt ist. Damit kommen dann die oben beschriebenen Probleme zustande.

Bei meinen eigenen Tests mit der aktuellen Firmware 1.6A reagiert die 2206 auf einen Disconnect mit cause value=[color=crimson]User busy[/color] immer mit Rückfall, wenn eine 010XX-Netzbetreiber-Vorwahl gewählt wurde. Bei der direkten Wahl über meinen Netzbetreiber (Telekom) (Haupt-Provider=“kein LCR” oder Rückfall-Provider=“kein LCR” oder 3. Versuch) vertraut die Anlage scheinbar darauf, dass die Disconnect-Nachricht mit cause value=[color=crimson]User busy[/color] korrekt ist, bricht das Rückfallen ab und signalisiert besetzt. Bei der Vorwahl 01033 (Telekom) verhält sich der Rückfall bei cause value=[color=crimson]User busy[/color] genau so wie bei allen anderen 010XX-Vorwahlen (also anders als bei direkter Wahl über meinen Netzbetreiber Telekom ohne 01033).

Wenn ich nun Preselection auf einen Provider mit falschem Disconnect einstellen lassen würde und diesem den ersten Versuch gebe (Haupt-Provider=“kein LCR”), müsste es wieder in der ursprünglichen Richtung danebengehen (keine Rückfall bei Nicht-Verfügbarkeit dieses Providers)…

Egal wie sich die Firmware der Firma Auerswald verhält: solange einige Provider sich nicht an das Protokoll halten, ist ein Fehlverhalten kaum auszuschließen. Ich wünsche mir aber dringend folgende Schadensbegrenzung:
[list=1]
[*] Wenn ein Rückfall als notwendig erachtet wird, sollte das dem Anrufer durch eindeutig identifizierbare Töne signalisiert werden (z.B. Sonderwählton). Das ist auch gut, wenn wirklich ein Rückfall richtig (weil Provider überlastet) ist: Da weiß man, ab wann es wirklich klingelt bzw. dass man nicht abgewiesen wurde, kann sich auf eine etwas teurere Verbindung einstellen oder evtl. auch schnell auflegen, wenn man den Rückfall nicht will.

[*] Der Rückfall sollte (uhrzeit- und nummernabhängig) abschaltbar sein. Ich kann zwar jeweils bei dem Rückfall-Anbieter “kein LCR” einstellen, aber nicht verhindern, dass ein zweiter Versuch über meinen Netzbetreiber (Telekom) gemacht wird. Auch das ist wichtig, selbst wenn der Grund für den Rückfall korrekt erkannt wird, weil mancher lieber noch einmal wählt, als z.B. Mobil- oder Auslandsgespräche über den eigenen Netzbetreiber (z.B. Telekom) zu führen. Die derzeitige Variante hat in dieser Hinsicht entscheidende Nachteile gegenüber dem LCR ohne Rückfall!!!

[*] Toll wäre eine Einstellmöglichkeit je Provider, in der man angeben kann, ob dieser Provider korrekte Disconnect-Nachrichten übermittelt. Schließlich machen das ja nicht alle Provider falsch. Dann kann die Anlage danach entscheiden, wie sie sich z.B. bei cause value="[color=crimson]User busy[/color]" verhält. Evtl. könnte die Anlage das ja auch selbst lernen:cool:
[/list=1]
Mir persönlich wäre im Übrigen die alte Variante, bei der manchmal der Rückfall nicht klappt, immer noch lieber als die aktuelle. Dann würde ich mir als Haupt-Anbieter Provider mit korrekter Signalisierung heraussuchen, während ich jetzt gar keinen Einfluss auf das Fehlverhalten habe.

Was haltet Ihr von der ganzen Problematik? Ich werde gleich mal noch eine kleine [color=BLUE]Umfrage[/color] zu meinen Vorschlägen erstellen.

Nun kann ich nur hoffen, der Beitrag war nicht zu lang (zum Lesen)…:o :slight_smile: :o

Viele Grüße
Andreas

Hallo!

Schön das das mal jemand niedergeschrieben hat. Ich hatte bisher keine Lust das so detailliert zu beschreiben (hätte ich auch nicht gekonnt, technisch bin ich da nämlich eher weniger bewandert), aber das beschriebene Verhalten stört mich auch ganz fürchterlich.:a :a

Ein starkes Argument FÜR diesen Sonderton ist: Wenn man einen güstigen CBC nutzt, der leider keinen Ansage hat, weiß man z.B. gar nicht ob man über CbC oder die Telekom telefoniert und dann anstelle der 7ct nach Südafrika locker 1,19 Euro pro min bezahlt. Und man merkt es nicht !!!:a :a :a

Und außerdem meiner Frau das rumgeknacke und gepiepe zu erklären (bei einem ganz normalen Besetzt des Teilnehmers) gestaltet sich auch immer wieder aufs neue relativ schwierig :wink: :wink:

Ich hoffe das Auerswald da was dran dreht!!

Grüße
Achim

Hallo

das ist gut, daß sich mal jemand die mühe gemacht hat und das Verhalten der Anlage analysiert hat!! Hast Du mal ein D-Kanal mit diesen Untersuchungen an Auerswald geschickt? Ich denke, daß es dann eventuell schneller gefixt werden wird.
Das Problem mit der Anzeige bzw. Signalisierung der Rückfallprovider ist bei mir kein Problem. Ich nutze ein COMfort 2000 und der aktuelle Provider wird im Display eingebelndet. Dies sollte auch bei anderen ISDN-Geräten funktionieren, da die Meldung zu dem Provider als Display-Meldung über den D-Kanal versendet wird. Bei analogen Geräten ist das natürlich ein Problem. Eventuell findet sich ja eine Lösung.

Tschau

Ach, daran liegt das. Ich dachte, diese komischen Töne würden von CbC-Providern verursacht, die bei uns in der Gegend kein CbC im Ortsnetz anbieten, aber trotzdem in der Routingtabelle drin sind (z.B. 01013 ist so ein Fall, IIRC)… das Phänomen trat bei mir zufällig nur bei Ortsgesprächen auf, daher die Annahme.

Hmm, hat vielleicht zufällig jemand eine Liste “schwarzer Schafe”, die besetzt statt Netzauslastung signalisieren? Dann würde ich die nämlich boykottieren und aus meiner LCR-Tabelle verbannen… wozu gibts denn Standards, wenn man sich nicht dran hält!? (“The good thing about standards is that there are so many to choose from”, jaja, ich weiß…:slight_smile: ) Also, auf die paar Cent kommts mir beim Sparen nicht an; ich hab glücklicherweise keine extremen Auslandsziele dabei, also leiste ich mir den Luxus, die Schlamper zu bestrafen.

Sozusagen halt ich es da wie mit meiner ISDN-Anlage: lieber etwas mehr ausgeben und dafür etwas Besseres kriegen :wink:

Mir ist da noch etwas eingefallen: Wenn man eine Preselection auf einen Provider einstellen lässt, den es gar nicht gibt, müsste das Problem mit dem unbeeinflussbaren 3. Versuch nach dem 2. Rückfall eigentlich geklärt sein :smiley: :smiley: :D.
Für Haupt- und Rückfall-Anbieter stellt man dann halt was vernünftiges ein, evtl. auch 01033.

Nun die Preisfrage: Kann man einen falschen Provider per Preselection einstellen lassen? :eek:

Aber es reicht ja auch schon, einen Provider mit halbwegs sinnvollen Preisen einstellen zu lassen. Eigentlich hatte ich gedacht, eine Preselection würde ich dank Auerswald nie benötigen, aber dank der neuen Anlage mit LCR-Rückfall macht das nun schon Sinn, solange sich nichts ändert… :mad:

Andreas

@windowikea:
COMforts habe ich keine. Mein ISDN-Telefon zeigt nur die Nummer, die ich eingetippt habe; laut S[SIZE=1]0[/SIZE]-Analyse wird auch keine Nummer an das ISDN-Telefon zurückübertragen, wenn der angerufene Teilnehmer besetzt ist.

@ALLE:
Eine Umfrage zum Thema findet Ihr [color=BLUE]hier[/color].

Andreas

Moin,moin,

ich kann Euer Problem mit dem Verhalten ja verstehen, aber man kann generell nicht unterscheiden, ob ein Teilnehmer oder der Provider belegt ist?

Wenn sich alle Provider daran halten würden, wäre es ja kein Problem. Es gibt ja eine Meldung, die für ein besetztes Netz verwendet werden kann (no circuit available), nur macht es kaum einer.

Die Anlage kann einen besetzten Teilnehmer von einem besetzten Netz nicht unterscheiden, da die Masse der Provider “User busy” oder noch schlimmer eine Ansage bringt. Das Disconnect kommt zudem nicht sofort, sondern mit einer Verzögerung. Und selbst ein korrekt signalisierender Provider schickt ein Disconnect mit dem cause “no circuit available”.

Dann kommen noch andere Faktoren hinzu. Hat der Zielteilnehmer eine Tk-Anlage, die sich bei einem kommenden Ruf Zeit verschafft, um die interne Rufverteilung zu kontrollieren (bei Mehrgeräteanschlüssen macht das jede Anlage!) oder hat er seinen Anschluss auf sein Handy umgeleitet? Das sind Dinge, die nicht übersehen werden dürfen.

Die Anlage muss bei aktiviertem LCR blitzschnell reagieren und aus einer nicht gerade kleinen Tabelle neue Providerkennziffern vor die eigentliche Rufnummer stellen und die Wahl jedes mal aufs Neue durchführen.

Nun kann ich leider das LCR easy meiner 4406 nicht mehr verwenden, da ich Arcor pre-selected bin. Vorher habe ich aber immer auf meinen ISDN-DECT- und COMfort-Systel die gewählten Provider gesehen und wusste somit, das gerade ein Fallback stattfindet.

Das “mißverständliche” Verhalten der Anlage bei Fallback sollte auch gar nicht so fremd sein, da es auch ohne LCR auftreten kann (nicht selten), wenn man z. B. in ein Mobilfunknetz telefoniert. Einen Sonderwählton während des Fallbacks würde mich u. U. aber mehr stören.

Hallo ISDN-Freak Olli,

also ich habe jetzt verstanden, dass Dich das “rumgeknacke und gepiepe” (von Achim treffend formuliert) nicht stört und Du keinen Sonderton willst. Schließlich passiert das so ähnlich auch ohne LCR. Außerdem verwendest Du sowieso kein LCR, und unsere Probleme treten demzufolge alle bei Dir nicht auf. Und wenn Du LCR hättest, dann hast Du auch noch genügend Systemtelefone, die Dich korrekt informieren könnten…

Ansonsten kann ich leider nicht verstehen, worauf Du eigentlich hinauswillst: Du erklärst verschiedene Gründe für Verzögerungen, die ja die Ursache für das entsetzlich lange “rumgeknacke und gepiepe” sind, aber man hat beim Lesen das Gefühl, dass es eigentlich eine Entgegnung auf die vorherigen Artikel ist - was es aber nicht ist. Oder? Ich möchte das jetzt nicht weiter auseinandernehmen. Aber: Wir habe diese Dinge nicht übersehen!
Falls es eine Entgegnung sein sollte, dann schreibe mir bitte noch mal konkret auf, was an meinem Beitrag oben falsch ist!

Bei mir ist die Situation folgende:

Ich versuche jetzt seit Tagen, einen überlasteten Netzbetreiber zu finden, um mir die Nachrichten anzuschauen. Finde keinen. Die einzigen Erfolge habe ich bei Ortsnetz-Anbietern, die keine Gespräche im Ortsnetz können. Da bekomme ich korrekt und sofort Disconnect mit cause=“switching equipment congestion” und nach etwa 2 Sekunden beginnt schon der 3. Wählversuch. (Die langen Verzögerungen kommen, wie Du auch geschrieben hast, hauptsächlich durch angerufene TKA zustande, die erst nach einigen Sekunden “User busy” melden und wo ein Rückfall ja auch fehl am Platz ist).

Ich hätte also wahrscheinlich kaum das Problem, dass ein Netzbetreiber überlastet ist. Aber ich habe das Problem mit den Tönen bei einer besetzten Gegenstelle und dass ich keinen CCBS (Rückruf bei Besetzt) außer über die Telekom nutzen kann und dass ich mit ein wenig Pech selbst bei nicht überlasteten anderen Netzbetreibern über die Telekom telefoniere, ohne das richtig mitzubekommen. Wenn der LCR-Rückfall schon nicht richtig funktioniert, dann möchte ich ihn wenigstens abschalten können!

Weil es aber auch andere Leute gibt, die doch LCR-Rückfall benötigen, habe ich mir mehr Gedanken gemacht und Vorschläge aufgeschrieben, wie man den LCR-Rückfall in den Griff bekommen und damit allen helfen könnte. Da es auch Provider gibt, die korrekte Nachrichten senden, wäre es ja nicht unmöglich…

Andreas

Hi,

ich habe das, was Ihr geschrieben habt schon richtig verstanden.

Das Problem liegt darin, das es immer Provider geben wird, die es halt nicht richtig machen. Man muss dabei auch überregional betrachten. Wenn bei mir z. B. Arcor sich korrekt verhält (nicht pre-selection), bedeutet das nicht, das Arcor das auch z. B. in München tut! Somit muss man bei jeder Meldung vom Amt davon ausgehen, das es ein besetztes Netz sein könnte und den Rückfall einleiten. Die Anlage kann aber vorher nicht wissen, wie oft ein Rückfall stattfinden wird. Es könnte ja frei sein und sie müsste das Freizeichen zum internen Telefon durchreichen. Damit das alles zügig und ohne NF-Verlust realisiert werden kann, wird man sich immer auf die Meldungen (inband info now available) vom Amt verlassen und ggf. die Töne (NF) durchreichen. Wenn es ein Besetztzeichen ist, höre ich halt ein Besetzt. Die Anlage wählt noch mal und noch mal usw.
Das würde also bedeuten, das jeder User selber rausbekommen müsste, ob seine verwendeten Provider sich evtl. bei einem besetzten Netz korrekt verhalten. Wie soll das ein Normalsterblicher machen? Bei jedem Provider mit D-Kanal-Protokollierer horchen, ob bei einem besetzten Netz der richtige Cause im Disconnect mitgeschickt wird?
Das Verhalten bei einem besetzten Netz ist der ETSI zwar beschrieben, leider aber keine Mussbestimmung. Somit kann jeder Provider machen was er will, z. B. ein Busy senden oder eine Ansage mit einer Alternativrufnummer schalten. Ist schon schön das Euro-ISDN.

Das Fallback abschaltbar zu machen, wäre auch schön. Ich glaube, das es eine menge User gibt, die das brauchen. Somit stimme ich Euch ja auch teilweise zu.

Ich bin halt nur anderer Meinung bezüglich des Sonderwähltons.

Hallo Olli,

Ich stimme Dir zu, dass sich das Problem nie ganz richtig lösen lassen wird. Ich könnte mir aber folgende Variante vorstellen, die recht gut funktionieren sollte:
[list]
Mittels SoftLCR kann über eine Einstellung ("für erfahrene Anwender") für jeden Provider die Aktion für “User busy” ausgewählt werden zwischen:

Rückfall / Abbruch / automatisch (Standardeinstellung ist automatisch.)

Wenn ein Anwender öfters bemerkt, dass bei einem bestimmten Haupt-Provider bei einem besetzten Anschluss unnötigerweise mehrere Versuche unternommen werden, ansonsten aber nie Probleme mit dem Anbieter autreten, stellt er von Hand auf Abbruch. Wenn er dagegen mehrfach feststellt, dass ein Gesprächspartner mit dem automatischen LCR nicht erreichbar ist, obwohl er mit manuellem LCR erreichbar ist bzw. dieser angibt, nicht besetzt gewesen zu sein, stellt er für den betroffenen Provider Rückfall ein.
Dazu braucht der Anwender keinen D-Kanal-Analysator und kein spezielles ISDN-Wissen - ODER? Jeder, der SoftLCR manuell einstellen kann, kann auch das.

Bei der Standardeinstellung automatisch könnte die Anlage entweder einfach das tun, was die Firma Auerswald für richtig hält, oder z.B. folgenden Algorithmus verwenden:

Zunächst arbeitet die Anlage so, wie bei Einstellung Rückfall. Wenn über einen Zeitraum bei allen Verbindungsversuchen je Provider, bei denen dieser “User busy” meldet, auch die Rückfallprovider immer “User busy” melden, davon mindestens 10 Verbindungsversuche jeweils einen Abstand von mindestens 1 Stunde und mindestens einen dazwischenliegenden erfolgreichen Verbindungsaufbau über diesen Provider haben, wird Abbruch eingestellt. Wenn dagegen bei 3 aufeinanderfolgenden Verbindungsversuchen je Provider dieser “User busy” meldet, aber über einen Rückfallprovider ein Gespräch zustandekommt, wird Rückfall fest eingestellt.
[/list]
Das Verfahren klingt jetzt möglicherweise etwas kompliziert, aber die Algorithmen für die Umsetzung in der Firmware sind (wirklich) ganz einfach. Und besser als die bisherigen Varianten sollte es (nach einer Weile) in jedem Fall funktionieren.

Bei allen Disconnect-Gründen, bei denen derzeit ein Rückfall verwendet wird, kann ja auch weiterhin Rückfall durchgeführt werden(?)

Ich sehe ein, dass der B-Kanal sofort nach Verbindungsaufbau durchgeschaltet werden muss, um NF-Verlust zu vermeiden. Dann kann man zwischen Wahl und Disconnect keine speziellen Töne erzeugen. Man könnte aber zwischen der Entscheidung, einen Rückfall durchzuführen, und der nächsten Wahl für eine Sekunde einen Sonderton einblenden. Auf diese eine Sekunde kommt es bei den ganzen Verzögerungen nun wirklich auch nicht mehr an.

Du schreibst "Wenn es ein Besetztzeichen ist, höre ich halt ein Besetzt. Die Anlage wählt noch mal und noch mal usw." Das funktioniert aber leider nicht (mehr?) so. Würde ich kurz besetzt hören, würde mir das als Signalisierung völlig ausreichen, um zu wissen, dass es einen Rückfall gibt, und mein Wunsch nach Sondertönen wäre nie aufgekommen. Evtl. lehnst Du auch daher den Sonderton ab? Ich habe zwischen den Wählversuchen allerdings noch nie etwas gehört, was ich als Besetztzeichen hätte interpretieren können. Stattdessen klingt es häufig wie ein Freizeichen mit bis zu 3 Tönen. Das ist irreführend!

Noch einen schönen Sonntag!
Andreas

Mmmmmhhhh,

die Idee ist auf jeden Fall nicht schlecht und würde in unserer Jacotec-Gemeinde sicherlich auch funktionieren, was machen aber die DAUs? Kommen die damit auch klar? Wäre eine echte Herausforderung der Handbuchabteilung von Auerswald.

Aber die Idee finde ich trotzdem toll.

Hallo,

Die Einstellung soll ja nur von “erfahrenen Anwendern” von Hand geändert werden :wink:

Ansonsten greift die Automatik. Die würde das auch nicht schlechter machen, als der “erfahrene Anwender”, weil sie das gleiche macht. Nur ohne die Aussage des Gesprächspartners “ich hab doch gar nicht telefoniert - kann gar nicht besetzt gewesen sein…” nutzen zu können. Deshalb dauert es etwas länger, bis die Einstellungen richtig sind.

Die DAUs bekommen einfach gesagt, “das wird sich schon von selbst richten”, falls sie ein Fehlverhalten bemerken. Wobei ich aber denke, dass alle die, die bemerken, dass das LCR etwas falsch macht, auch in der Lage sind, die Einstellung vorzunehmen.

Andreas

Die Idee für das automatische Verfahren ist echt nicht schlecht! Allerdings sollte die Anlage auch bei Providern, die sie nach einiger Zeit automatisch auf „Abbruch“ gesetzt hat (weil die sich ans Protokoll halten) ab und zu sicherheitshalber eine Art Überprüfung machen… denn das Problem, was ISDN-Freak beschrieben hat…:

…das könnte dazu führen, dass ein vormals „guter“ Anbieter plötzlich Mist (also den falschen Cause) liefert, weil er seine Netzinfrastruktur umgestellt hat.

Oder vielleicht sogar, weil man wegen Congestion ab und zu mal über ganz komische Pfade in seinem Netz geroutet wird (denn im Gegensatz zu Internet-Backbones wird im Telefonnetz ja z.T. wohl auch lastabhängig geroutet), und dann evtl. mal von einem Switch „in der Pampa“ auch einen falschen Disconnect kriegt. Letzteres ist aber Spekulation, da ich zugegebenermaßen nicht weiß, von wem man letztendlich den Cause kriegt.

Oder schlicht und einfach, weil man umgezogen ist und jetzt an einer anderen Vermittlungsstelle dranhängt. Wenn man innerhalb derselben Vorwahl umzieht, ändern sich oft nichtmal die eigenen MSNs; die Anlage hätte also keine Chance, das mitzukriegen.

Die Überprüfung könnte so aussehen:
Sobald die Automatik einen Provider auf „Abbruch“ gestellt hat, führt sie zu diesem Provider über die letzten, hmm, sagen wir 3 Anrufe Buch. Wenn die letzten 3 Anrufe über diesen Provider alle „besetzt“ waren, dann wird dieser Provider „verdächtig“, und dann macht sie sicherheitshalber doch mal ein Fallback auf den nächsten Provider. Liefert der auch ein Besetzt, dann wird’s wohl stimmen. Liefert der aber plötzlich ein Freizeichen, dann setzt die Automatik das Verhalten für den vormals auf „Abbruch“ gestellten Provider wieder auf „Rückfall“ (und Ahes Algorithmus beginnt wieder von vorne, falls der Provider wieder zu den „Guten“ wechselt).

Vielleicht kann man diesen „Sicherungsalgorithmus“ auch noch etwas verfeinern, indem man sich nicht nur merkt, ob das Gespräch erfolgreich oder erfolglos war, sondern auch die Nummer: Wenn der Benutzer 3x hintereinander dieselbe Person angerufen hat und da besetzt war, dann ist dort vielleicht einfach besetzt. Wenn aber der Benutzer über diesen Provider 3x hintereinander verschiedene Nummern angerufen hat und die alle (angeblich) besetzt waren, dann ist der Provider ganz sicher verdächtig und daher sollte die Anlage auf jeden Fall einen Gegencheck machen.

Die Zahl 3 hab ich etwas willkürlich gewählt, vielleicht nimmt man ja auch besser ne andere Zahl. Das Prinzip sollte aber klar sein.

Ist ähnlich wie der Algorithmus von ahe: Klingt vielleicht ein bissel kompliziert, sollte aber nicht viel Speicher kosten und auch eher einfach zu programmieren sein. Notfalls kann ich das ganze auch nochmal in Pseudocode aufschreiben. :wink:
Klar, man muss natürlich Sonderfälle berücksichtigen, z.B. dass der Rückfallprovider „Netzabschnitt belegt“ meldet (dann muss man es vielleicht beim nächstenmal testen, oder auf den dritten Provider rückfallen), oder dass der Rückfallprovider selbst zwar ebenfalls „besetzt“ meldet, durch dieses Besetzt vielleicht aber selbst ebenfalls „verdächtig“ geworden ist und selbst auch gecheckt werden müsste. Das sollte das Programm aber eigentlich nicht verkomplizieren, wenn man den Algorithmus richtig implementiert.

Hallo hirvi,

ja, daran hatte ich auch schon mal gedacht, dass man auch mit Verschlechterungen bei den Providern rechnen muss, aber erst mal weggelassen, damit es nicht so kompliziert aussieht…:wink: Das “verdächtig machen” bei 3x hintereinander bei verschiedenen Nummern “user busy” und dann Neustart im Anfangszustand als Erweiterung meines Verfahrens klingt gut. Da könnte man dann auch die von mir auch willkürlich gewählte Zahl 10 etwas verkleinern (ist falsch ausgedrückt, ich weiß…), weil es ja dann nicht so schlimm ist, wenn man ganz ganz selten mal falsch auf “Abbruch” stellt, weil es sich ja wieder korrigiert. Auch ist es nicht mehr notwending, fest auf “Rückfall” zu stellen, weil das sowieso nur eine Sperre war, um zu vermeiden, dass irgendwann zufällig doch mal noch falsch auf “Abbruch” gestellt wird.

Der einzige Sonderfall, der mir jetzt einfällt, ist, dass bei den (früher 10) Verbindungsversuchen mit “user busy” ein weiterer (mittlerer) Versuch (falls vorhanden) einen anderen Grund für Disconnect bringt und erst der letzte Versuch wieder “user busy”. Man könnte natürlich auch den Provider des 2. Versuches mit prüfen lassen. Ich fasse mal zusammen:
[list]
Zunächst wird für die Automatik für jeden Provider (unabhängig von der anwenderkonfigurierbaren Einstellung) intern der Zustand Rückfall eingestellt.

[*]Für Provider, die im Modus automatisch und dabei im internen Zustand Rückfall sind:
Wenn über einen Zeitraum bei allen Verbindungsversuchen je Provider, bei denen dieser durchgehend im Zustand Rückfall ist, bei Rückfall nicht den letzten Versuch hat, “User busy” meldet und wenigstens der letzte Rückfallprovider des gleichen LCR-Rückfall-Vorgangs immer “User busy” meldet, davon mindestens 5 Verbindungsversuche jeweils einen Abstand von mindestens 1 Stunde und mindestens einen dazwischenliegenden erfolgreichen Verbindungsaufbau über diesen Provider haben, wird intern auf Zustand Abbruch übergegangen.

[*]Für Provider, die im Modus automatisch und dabei im internen Zustand Abbruch sind:
Wenn über einen Zeitraum ein Provider durchgehend im Zustand Abbruch ist und bei allen Verbindungsversuchen “User busy” meldet und mindestens 3 Verbindungsversuche davon unterschiedliche Zielrufnummern haben, wird intern auf Zustand Rückfall übergegangen.
[/list]

Das ganze als Pseudocode (oder Programmablaufplan) aufschreiben ist eine gute Idee! Warscheinlich einfacher, kürzer und verständlicher als die chaotischen Sätze oben…

Aber die ganze Automatik soll nicht davon ablenken, dass der Rückfall trotzdem b[/b] zeit- und vorwahlabhängig abschaltbar (kein oder nur ein Rückfall auf auswählbaren Anbieter sollte ermöglicht werden!) sein soll (auch bei korrektem disconnect-Grund!) und auch b[/b] das Verhalten bei "user busy" auch von Hand providerabhängig konfigurierbar sein sollte, weil die Automatik, obwohl wahrscheinlich wirklich nützlich, manchen nicht-DAU’s evtl. auf die Nerven gehen könnte.

Andreas

Hallo,

habe endlich mal einen überlasteten Provider gefunden. Der liefert selbst bei gleichen Rufnummern(!) munter abwechselnd Disconnect cause=[color=red]“user busy”[/color] und Disconnect cause=[color=red]“no circuit/channel available”[/color].

Insofern sich nicht alle Anbieter sich so verhalten, funktioniert das “selbst lernen lassen” nach den bisher vorgeschlagenen Konzepten aber trotzdem, weil ja nur unterschieden werden soll zwischen Anbietern, die Disconnect cause=“user busy” nie falsch verwenden und denen die es (manchmal oder immer) falsch verwenden.

Ich habe aber noch eine deutlich einfachere, überschaubarere und möglicherweise bessere Lösung gefunden, die auch von Anfang an funktioniert: Bei meinen Tests gerade eben kam das Disconnect in beiden Fällen bereits vor der Wahl der vollständigen Nummer. Bei einer Nummer 1 Ziffer nach der 6-stelligen Vorwahl, in einem anderen Fall 2 Ziffern nach der 4-stelligen Vorwahl. Von vorn oder ab nach der Vorwahl zu zählen hat wohl keinen Sinn (siehe auch [color=blue] Compact4410USB und LCR-Fallback[/color]). Wie wäre aber folgendes Verfahren:
[list]
Mittels SoftLCR kann über eine Einstellung ("für erfahrene Anwender") für jeden Provider die Aktion für “User busy” ausgewählt werden zwischen:

Rückfall / Abbruch / automatisch (Standardeinstellung ist automatisch.)

… (siehe oben)…

Bei der Standardeinstellung automatisch könnte die Anlage entweder einfach das tun, was die Firma Auerswald für richtig hält, oder z.B. folgenden Algorithmus verwenden:

[color=darkred][SIZE=1][COLOR=orange] * * * GANZ ANDERES VERFAHREN ALS IN VORHERGEHENDEN BEITRÄGEN * * *[/color][/SIZE]
Meldet ein Provider Disconnect mit cause=[color=red]“User busy”[/color], wird nicht sofort der LCR-Rückfall begonnen, sondern zunächst die gleiche Nummer noch einmal gewählt, aber vor der letzten Ziffer eine Pause (ein klein wenig länger als die Zeit, die beim ersten Versuch zwischen der Wahl und der Disconnect-Nachricht verging) eingefügt. Wenn während dieser Pause eine beliebige Disconnect-Nachricht kommt, wird der Rückfall eingeleitet. Ansonsten wird die letzte Ziffer gewählt und nur wenn ein Disconnect mit cause ungleich [color=red]“User busy”[/color] folgt, wird ebenfalls zum LCR-Rückfall übergegangen. (Bei besetzt ist dann schon der richtige Provider für den Rückruf gewählt!) Falls nach dem ersten Disconnect noch weitere Ziffern zur Nummer dazukommen (langsame manuelle Wahl), kann man direkt zum Rückfall übergehen, weil dann die Rufnummer noch nicht vollständig war, als Disconnect kam, was wieder nur am Provider liegen kann.
[SIZE=1][color=orange] * * * GANZ ANDERES VERFAHREN ALS IN VORHERGEHENDEN BEITRÄGEN * * *[/color][/SIZE][/COLOR]
[/list]
Wie wäre das?

Andreas

…was mir gerade aufgefallen ist:
Wenn LCR-Rückfall bei einer Nummer passiert, die im Telefonbuch steht, sehe ich nicht einmal am Systemdisplay irgendwas davon. Da steht immer nur der Name des Angerufenen… Ist das bei den COMforts auch so?

[color=red]@ALLE LCR-USER[/color]
[color=darkred]Bitte testet alle mal mit, ob man einen überlasteten Provider von einem besetzten Anschluss wirklich nach dem Algorithmus in meinem letzten Beitrag unterscheiden kann, also ob bei einem überlasteten Provider schon vor der Wahl der letzten Ziffer besetzt ist (vor letzter Ziffer evtl. kurz warten).[/color]

Danke!
Andreas

Moin moin

bei einem COMfort siehst Du welcher Provider gewählt wird! Zumindest wird der Name des Providers bei einem Rückfall angezeigt.

Tschau

Hi, da braucht man nichtmal ein COMfort dafür… das zeigt sogar mein billiges ISDN-Telefon “Audioline Terminal E1” (oder so ähnlich) an. War ich ganz schön baff, als ich das zum ersten Mal gesehen hab.

Wie ich in einem anderen Thread lesen konnte, aber nur mit dem Soft LCR Easy. Oder geht das mittlerweile auch mit dem manuellem SoftLCR ?

Grüße
Achim

P.S. An meinem Comfort wird nämlich kein Provider angezeigt.

Das geht nur mit dem SoftLCR Easy!