i-Telex-Fehlermeldungen

[BjoernS]

Hallo zusammen,

ich "schraube" gerade an meinem T1000 mit piTelex herum, an der Tastaturwahllogik. Wenn man z.B. mit Tastaturwahl eine nicht existierende Nummer wählt oder der angewählte besetzt ist, schaltet der FS bei piTelex einfach ab. Wie macht das i-Telex? In der Gesamtbeschreibung steht nur

Wenn die gerufene Stelle frei ist, läuft diese an und die Verbindung ist hergestellt. Wenn die gerufene Stelle besetzt ist, schaltet sich der eigene Fernschreiber wieder ab.

Ich weiß aber, dass es diverse Fehlercodes gibt und i-Telex auch einige davon umsetzt. Über den i-Telex-Quellcode bin ich zu folgenden Vermutungen gelangt. Das Ganze habe ich mit der Anleitung der T1000 abgeglichen, dort stehen kurze Beschreibungen einiger Fehler drin.

Fehlermeldung	Funktion i-Telex	Beschreibung in Anleitung T1000
occ	Gehende TCP-Verbindung zu Teilnehmer kann nicht hergestellt werden	Teilnehmer besetzt
nc	ModRuhe ("Nicht mehr über den Remoteserver verbunden")	Leitung bzw. Vermittlung besetzt
na	scheint nur auf von außen kommende Durchwahlen angewendet zu werden	nicht erlaubte Verbindung (Nummer)
np	findet sich nur im Kommentar "Liste der Dienstkürzel" als "der Verlangte ist nicht oder nicht mehr im Telex-Teilnehmer"	nicht vorhandene Verbindung (Nummer)
der	Scheint hauptsächlich mit E-Mail zu tun zu haben	Störung
abs	In ModDeaktiviert ("Durch Tastendruck ausgeschaltet")	(fehlt)
bk	Quittierung des Wahlabbruchs nach 15 s	(fehlt)

Mein akutes Ziel ist, diese Fehlermeldungen in piTelex nachzurüsten, um ein einheitliches Verhalten beider zu erreichen.

Ich freue mich über sachdienliche Hinweise, insbesondere zu nc, na, der, abs

Danke und Grüße


Björn

[FredSonnenrein]

Hallo Björn,
so ist es richtig

nc: TCP-Verbindung kann nicht hergestellt werden (A)
occ: Anschluss besetzt (B)
na: Gewählte Durchwahl ist nicht freigegeben (B)
der: Anschluss scheinbar frei, angewählte Maschine läuft aber nicht an (B)
abs: Anschluss deaktiviert (A/B)
bk: Wahlabbruch (weil gewählte Nummer nicht im Teilnehmerverzeichnis vorhanden) (A)
np: wird nicht verwendet.

Meldungen (A) generiert das rufende System, Meldungen (B) kommen mit dem Reject-Paket vom gerufenen System.

Grüße,

Fred

[BjoernS]

Optimal, danke!

Grüße


Björn

[BjoernS]

Hallo nochmal,

mir stellt sich gerade noch eine Frage die Durchwahlen betreffend. Im Teilnehmerserver sind ja alle Anschlüsse inkl. Durchwahl hinterlegt. Ein Client muss sich also erst mit IP-Adresse/Port verbinden und dann das direct-dial-Paket mit der Durchwahl senden, um wirklich mit dem richtigen Teilnehmer verbunden zu werden (hier gab es bei piTelex ein Problemchen, das aber einfach zu beheben war).

Ist bei i-Telex vorgesehen, Durchwahlen auch explizit zu wählen? In der Doku steht etwas von Nachwahlziffern:

Für eine interne Verbindung ist die Nebenstellennummer zu wählen, für ausgehende Verbindungen die nacheinander die Amtswahlziffer, die Rufnummer des i-Telex-Partners und ggf. die Nachwahlziffer (nur bei Verbindungen über die analoge Leitungsschnittstelle). Die Nachwahlziffer muss mit etwa 3 Sekunden Abstand gewählt werden.

Oder ist das ein Relikt von TelexPhone? ("Analoge Leitungsschnittstelle"?) Aktuell kann ich mir nicht vorstellen, wie das funktionieren soll, wenn die Durchwahl doch schon vom TNS bekannt ist.

Grüße


Björn

[Fernschreiber]

Hallo Björn
dieser Punkt hat bei mir damals (2016/17) dazu geführt, das ich das in meine Pythonsoftware implementiert habe. Später stellte sich heraus, das dieser Textabschnitt versehentlich von der Telexphoneseite übernommen wurde (Henning hat das dann gelöscht). Wahrscheinlich bin ich der einzige, der das mit seiner i-Telex Variante kann. technisch kein Problem, man überschreibt die DW vom Server mit der Nachwahl. Somit kann ich mit irgend einer Nummer eines Anschlusses jede Durchwahl erreichen, hat zu Testzwecken durchaus Vorteile. Die 3 sek sind aber etwas Übungssache. Diese Variante ist ebenfalls im Webgateway (telex.telephontechnik.de:82) von mir auch noch drin. Für Tests auch ohne Servereintrag echt praktisch.
Gruß
Willi

[BjoernS]

Moin Willi,

das ist ja interessant. Habe auch schon mit dem Gedanken gespielt, wenn das wirklich ein Überbleibsel von TxP ist, es trotzdem für Tests einzurichten. Statt dieser Pause zwischen den Ziffern schwebt mir aber eher eine Tastaturwahl mit Nummer-Bindestrich-Durchwahl vor. Leider hätten dann Nicht-Tastaturwähler das Nachsehen, aber es ist ja nur eine Test-Funktion.

Grüße


Björn

[FredSonnenrein]

Da der Teilnehmerserver nun genug Kapazitäten hat, kann jeder am i-Telex hängender Fernschreiber mit seiner Kennung abgelegt werden.
Wer tatsächlich Fernschreiber mit den Kennungen 33355511 und 33355512 und 33355513 besitzt, bekommt diese auch.
Und irgendwann kann man seine eigenen Einträge auch selbst verwalten.

[Fernschreiber]

Hallo Björn. Wir sollten die Nachwahl aus den Telexphone und die Durchwahl aus dem i-Telex nicht verwechseln oder mischen. Beim Telexphone war sie erforderlich, da der Zielort über eine unabhängige Telefonrufnummer erfolgte und nur durch "Nachwahl" ein bestimmtes Endgerät angesprochen werden konnte. Servereinträge gibt es da nicht. Im i-Telex wird der Zielport einzig durch das Durchwahlpaket (bzw. ohne >>Defaultnummer oder was immer) bestimmt. Die Telexrufnummer ist lediglich ein Wert (dessen Inhalt vollkommen egal ist,wird in der csv-Liste wie alle anderen Daten als String gehalten . Lediglich der Umstand, das die Serverabfrage numerische Werte erwartet zwingt dabei zur Benutzung von Zahlen), der die individuelle Zeile im Server markiert und damit die IP/Domäne und Port zur Kontaktaufnahme (TCP) bereitstellt. Dann erst wird die Durchwahlinfo im Protokoll direkt nach der Versionsaushandlung benutzt. Ein "verlängern" von Rufnummern, so wie es Fred angemerkt hat, ist weder möglich noch nötig. Einzig die DW-Info zählt.
Der Workaround der alten Nachwahl ist somit im i-Telex lediglich ein Gimmick, der aber zu Testzwecken durchaus seine Berechtigung hat wenn es schnell gehen soll und keine Dateieintäge (lokal wie im Server) beötigt. Du kannst Dir lokal in deiner Applikation wie ich gelesen habe durchaus innovative Eingaben realisieren, aber wenn das Protokoll ins Spiel kommt gelten die definierten Daten im definierten Format, egal woher sie kommen..
Gruss
Willi

[BjoernS]

Danke für eure Ergänzungen. Ich denke es wäre sinnvoll, die diesbezüglichen Hinweise in der Doku anzupassen, um zukünftige Verwirrung zu vermeiden. (Würde auch unterstützen, wenn das ganze auf eine geeignete Plattform käme, wo mehrere ohne Chaos dran schaffen können.)



Björn

[FredSonnenrein]

Hallo Björn,

(Würde auch unterstützen, wenn das ganze auf eine geeignete Plattform käme, wo mehrere ohne Chaos dran schaffen können.)

Wiki und Sourceforge sind ungeeignet? (Bitte entschuldige die Stichelei)...