i-Telex Extension-Nummer (Durchwahl)

[detlef]

Ich dachte eigentlich, ich kenne mich einigermaßen gut aus mit der Konfiguration von i-Telex, aber das hier macht mich ratlos.

i-telex extension-problem.png

Man sieht hier in der i-Telex-Debug-Ausgabe einen eingehenden Aufruf vom News-Server. Als Durchwahl wurde die 12 übermittelt.
Rausgekommen ist die Nachricht aber auf der 21. Die 21 ist die Nummer, die in der Netzwerkkarte als Hauptnummer eingetragen ist.

Aber in der Netzwerkkarte habe ich "Weiterleitung bei besetzt: nein" eingetragen.
Und bei allen Anschlüssen (12 und 21) ist "Weiterleitung abweisen: ja" konfiguriert.
Die 12 war auch zur Zeit des Anrufs nicht besetzt. Das würde man in der Debug-Ausgabe sehen.
Da darf doch wohl unter keinen Umständen irgendwas weitergeleitet werden. Ich will das auch nicht, dass da irgendwas weitergeleitet wird.

Die Firmware-Versionen:

Ethernet-Karte: 966
Anschluss 12: 569 (serieller Anschluss der TW39/Seriell-Karte)
Anschluss 21: 556 (T1000-Karte)

Es wurde ja schon öfter von Problemen mit der Durchwahl berichtet. Könnte da vielleicht doch ein Bug in der i-Telex-Firmware sein?

[FredSonnenrein]

Hallo Detlef,

Ist denn die 12 in der. "Liste erlaubter Durchwahlen" (Option der Ethernet-Karte) enthalten? Wenn nicht, dann wird die Vorgabe der Nebenstelle des Anwahl-Telegramms ignoriert.

"Weiterleitung abweisen" bedeutet tatsächlich, dass trotz Einstellung "weiterleitung bei besetzt= ja" diese Nebenstelle niemals weitergeleitete Anrufe annimmt (z.b. bei Streifenschreiben sinnvoll.

Das Debug-Protokoll irritiert mich aber sehr. Welche Einstellung ist da aktiv?

Viele Grüsse

Fred

[detlef]

Ups. Sorry, ich wollte diese Nachricht noch gar nicht posten. Diese Forum verhält sich manchmal wirklich merkwürdig.

Beim Schreiben ist mir eingefallen, dass ich vielleicht erst nochmal im originalen Debug-Log nachschauen sollte, was da genau passiert. Denn die Ansicht auf dem Screenshot ist nur eine Zusammenfassung meines Logger-Programms.

Ich melde mich nochmal, wenn ich das geprüft habe.

[detlef]

Das Problem ist bisher nicht wieder aufgetreten. Scheint also zumindest bei mir hier kein akutes Problem zu sein.
Ich werde das weiter beobachten.

[detlef]

Jetzt hatte ich wieder den Fall. Der Nachrichtendienst schickt eine Nachricht auf die Durchwahl 12. Ankommen tut sie auf der 0. Es sieht so aus, als würde die Durchwahl nicht erkannt.

Hier das Log des Nachrichtendienstes - ausgehende Verbindung:

Code: Alles auswählen

12.09.2023 16:30:40.390 [Info ] [ItelexLogger] [ItelexLogger] --- start of logfile ---
12.09.2023 16:30:40.390 [Info ] [ItelexConnection] [ConnectIn] id=6679
12.09.2023 16:30:40.717 [Info ] [ItelexConnection] [ConnectOut] ConnectOut id=6679 to number=211231 ext=12 remote=92.117.83.165:131 
12.09.2023 16:30:40.733 [Debug] [ItelexConnection] [ConnectOut] debug outgoing connection extablished 92.117.83.165:131
12.09.2023 16:30:42.808 [Info ] [ItelexConnection] [SendCmd] send ProtocolVersion 1 ns201 [07 06 01 6E 73 32 30 31]
12.09.2023 16:30:42.823 [Info ] [ItelexConnection] [DataReceived] debug recv data=7 set ConnectionState to ItelexTexting
12.09.2023 16:30:42.823 [Info ] [ItelexConnection] [DecodePacket] recv ProtocolVersion 1 966 [07 05 01 39 36 36 00]
12.09.2023 16:30:42.917 [Debug] [ItelexConnection] [ConnectOut] debug after version wait ConnectionState=ItelexTexting RemoteVersion=1 ElapsedMilliseconds=109ms
12.09.2023 16:30:43.432 [Info ] [ItelexConnection] [SendCmd] send DirectDial 12 [01 01 0C]
12.09.2023 16:30:43.432 [Debug] [ItelexConnection] [ConnectOut] debug WaitForSilence after SendDirectDialCmd
12.09.2023 16:30:43.432 [Debug] [ItelexConnection] [WaitForSilence] debug WaitForSilence start min=4000ms silence=3000ms timeout=10000ms (caller=ConnectOut)
12.09.2023 16:30:44.867 [Info ] [ItelexConnection] [DecodePacket] recv Heartbeat [00 00]
12.09.2023 16:30:48.907 [Info ] [ItelexConnection] [DecodePacket] recv Heartbeat [00 00]
12.09.2023 16:30:52.651 [Info ] [ItelexConnection] [DecodePacket] recv BaudotData "<BU><BU><BU><BU><BU><BU><BU><CR><LF><ZI>12.09.2023  16:30<CR><LF>"

Und hier das zugehörige Log des i-Telex

Code: Alles auswählen

16:30:17,01: iTelex(33163): Server-Socket #0 geoeffnet von IP 92.117.83.165 / MAC 98:9b:cb:50:8d:ee ...neu ok
16:30:17,01: iTelex(33163): ModusWechsel von 0 nach 11.
16:30:18,97: iTelex(42953): Socket Empfang: (2/2) 00 00 --> BufUsed 2
16:30:18,97: iTelex(42954): Socket Empfang: (8/8) 07 06 01 'ns201' --> BufUsed 8
16:30:18,98: iTelex(42954): Protokollversion-Vorschlag 1 empfangen
16:30:18,98: iTelex(42954): Sende Protokollversion-Vorschlag 1
16:30:18,99: iTelex(42955): Socket Sendung: (7) 07 05 01 39 36 36 00 --> Res 7 SumAnz 0/00
16:30:19,55: iTelex(45199): Socket Empfang: (3/3) 06 01 00 --> BufUsed 3
16:30:19,55: iTelex(45199): ModusWechsel von 11 nach 13.
16:30:19,55: iTelex(45199): SeriellUmsetzInit: BusVerbPartner = 21, SerUmTicksProBit = 18
16:30:19,55: iTelex(45199): ! spontane ??? Anwahl intern 0 verbunden mit 21
16:30:19,60: iTelex(45313): Socket Empfang: (3/3) 01 01 0C --> BufUsed 3
16:30:21,04: iTelex(51966): Socket Sendung: (2) 00 00 --> Res 2 SumAnz 0/00
16:30:21,56: iTelex(54457): Socket Empfang: (3/3) 06 01 00 --> BufUsed 3
16:30:23,57: iTelex(64290): Socket Empfang: (3/3) 06 01 00 --> BufUsed 3
16:30:25,07: iTelex( 6132): Socket Sendung: (2) 00 00 --> Res 2 SumAnz 0/00
16:30:25,58: iTelex( 8633): Socket Empfang: (3/3) 06 01 00 --> BufUsed 3
16:30:27,60: iTelex(18575): Socket Empfang: (3/3) 06 01 00 --> BufUsed 3
16:30:28,81: iTelex(24550): TWI Einschaltquittung intern / kommend
16:30:28,81: iTelex(24550): ModusWechsel von 13 nach 14.
16:30:28,81: iTelex(24551): Socket Sendung: (34) 02 1D 1F 1F 1F 1F 1F 1F 1F 02 08 1B 1D 19 07 0D 03 07 19 0D 19 10 04 04 1D 15 0E 10 0D 02 08 06 01 E8 --> Res 34 SumAnz 29/1D

Fred, kannst du da irgendwas erkennen? Das Problem tritt, wie gesagt, nur ganz sporadisch auf.
Die 12 ist meine serielle Schnittstelle auf der TW39/Seriell-Karte.

Wenn alles richtig läuft, dann sieht das auf der i-Telex-Seite so aus. Da sieht man die Durchwahl-Anfrage.

Code: Alles auswählen

16:44:19,01: iTelex(11211): Server-Socket #0 geoeffnet von IP 92.117.83.165 / MAC 98:9b:cb:50:8d:ee ...neu ok
16:44:19,01: iTelex(11211): ModusWechsel von 0 nach 11.
16:44:20,72: iTelex(19789): Socket Empfang: (2/2) 00 00 --> BufUsed 2
16:44:20,72: iTelex(19790): Socket Empfang: (8/8) 07 06 01 'ns201' --> BufUsed 8
16:44:20,73: iTelex(19790): Protokollversion-Vorschlag 1 empfangen
16:44:20,73: iTelex(19790): Sende Protokollversion-Vorschlag 1
16:44:20,73: iTelex(19791): Socket Sendung: (7) 07 05 01 39 36 36 00 --> Res 7 SumAnz 0/00
16:44:21,34: iTelex(22262): Socket Empfang: (3/3) 01 01 0C --> BufUsed 3
16:44:21,34: iTelex(22262): Durchwahl-Anfrage 12
16:44:21,34: iTelex(22262): Durchwahl in Tabelle gefunden 12
16:44:21,35: iTelex(22262): ModusWechsel von 11 nach 12.
16:44:21,35: iTelex(22262): ModusWechsel von 12 nach 13.
16:44:21,35: iTelex(22262): SeriellUmsetzInit: BusVerbPartner = 12, SerUmTicksProBit = 18
16:44:21,36: iTelex(22262): Anwahl intern 12 verbunden mit 12
16:44:21,37: iTelex(22263): TWI Einschaltquittung intern / kommend
16:44:21,37: iTelex(22263): ModusWechsel von 13 nach 14.
16:44:21,39: iTelex(22264): Socket Sendung: (34) 02 1D 1F 1F 1F 1F 1F 1F 1F 02 08 1B 1D 19 07 0D 03 07 19 0D 19 10 04 04 1D 15 0E 0A 0A 02 08 06 01 E8 --> Res 34 SumAnz 29/1D

[detlef]

Gut, wenn man sich das selbst noch mal in Ruhe anschaut. Ich sehe jetzt im ersten Fall die Durchwahlanfrage im Log des i-Telex.
Die kommt zu einem Zeitpunkt, wo das i-Telex schon die "0" angenommen hat. Also wohl zu spät. Und wird ignoriert.

Ich schaue mal, wo das Delay in meiner Routine herkommt.
Wie lange wartet das i-Telex auf das Durchwahl-Kommando?

[FredSonnenrein]

Wie lange wartet das i-Telex auf das Durchwahl-Kommando?

Solange, bis ein Telegramm empfangen wird, welches den Fernschreiber einschaltet.
Dies ist entweder ein BAUDOT_DATA (0x02 ...) oder ein ACKNOWLEDGE (0x06)

Und das ist auch das Problem beim "Fehlschlag".
Die Daten
16:30:19,55: iTelex(45199): Socket Empfang: (3/3) 06 01 00 --> BufUsed 3
starten den Drucker, es wird die Hauptstelle verwendet, weil noch kein DIRECT DIAL empfangen wurde.
Das 01 01 0C kommt erst später.

Du kannst übrigens problemlos das Versionspaket und das Direct Dial in einem TCP Paket versenden.

Viel Erfolg bei der Fehlerbeseitigung.

Grüße,

Fred

[detlef]

Aha. Also nicht das Delay ist das Problem, sondern dass ich den Acknowledge zu früh starte.
Ich habe die Acknowledge-Aktivierung jetzt mal geändert und lasse das Delay drin. Das hatte ich glaube ich reingenommen, weil ich das piTelex an der Stelle überrannt habe und das dann durcheinander kam.
Als das Delay noch nicht drin war, gab es das Problem noch nicht. Da was nicht genug Zeit, das Acknowledge vor dem Diect-Dial zu senden.

[detlef]

Ich habe jetzt nochmal ein Problem, das zu diesem Thema passt. Wolfgang ruft mit der Firmware-Version 915 das E-Mail-Gateway an.
Hier die Mitschnitt der Verbindungsaufbaus:

Code: Alles auswählen

18:26:50,01: iTelex(44760): Server-Socket #0 geoeffnet von IP 212.241.93.250 / MAC 98:9b:cb:50:8d:ee ...neu ok
18:26:50,01: iTelex(44760): ModusWechsel von 0 nach 11.
18:26:50,01: iTelex(44760): Socket Empfang: (10/10) 07 05 01 39 31 35 00 01 01 0C --> BufUsed 10
18:26:50,02: iTelex(44760): Protokollversion-Vorschlag 1 empfangen
18:26:50,02: iTelex(44760): Sende Protokollversion-Vorschlag 1
18:26:50,02: iTelex(44760): Durchwahl-Anfrage 12
18:26:50,02: iTelex(44760): Durchwahl in Tabelle gefunden 12
18:26:50,02: iTelex(44760): ModusWechsel von 11 nach 12.
18:26:50,03: iTelex(44760): ModusWechsel von 12 nach 13.
18:26:50,03: iTelex(44760): SeriellUmsetzInit: BusVerbPartner = 12, SerUmTicksProBit = 18
18:26:50,04: iTelex(44760): Anwahl intern 12 verbunden mit 12
18:26:50,12: iTelex(44761): TWI Einschaltquittung intern / kommend
18:26:50,12: iTelex(44761): ModusWechsel von 13 nach 14.
18:26:50,16: iTelex(44761): Socket Sendung: (7) 07 05 01 39 36 36 00 --> Res 7 SumAnz 0/00

Man sieht hier, dass vom Öffnen der Socketverbindung bis zum Empfang des ersten i-Telex-Packets genau 0 Hunderstel Sekunden vergehen.
Socket geöffnet: 18:26:50,01
Socket Empfang: 18:26:50,01

Keine Chance, dass einer meiner Dienst da mitkommt. Mein Windows hier ist kein Echtzeitsystem.
Das erste Paket muss verloren gehen.

So macht das die Version 966:

Code: Alles auswählen

19:09:26,01: iTelex(20132): Server-Socket #0 geoeffnet von IP 92.117.81.237 / MAC 98:9b:cb:50:8d:ee ...neu ok
19:09:26,01: iTelex(20132): ModusWechsel von 0 nach 11.
19:09:26,61: iTelex(23059): Socket Empfang: (10/10) 07 05 01 39 36 36 00 01 01 0C --> BufUsed 10
19:09:26,61: iTelex(23059): Protokollversion-Vorschlag 1 empfangen
19:09:26,62: iTelex(23059): Sende Protokollversion-Vorschlag 1
19:09:26,62: iTelex(23059): Durchwahl-Anfrage 12
19:09:26,62: iTelex(23059): Durchwahl in Tabelle gefunden 12
19:09:26,62: iTelex(23059): ModusWechsel von 11 nach 12.
19:09:26,63: iTelex(23059): ModusWechsel von 12 nach 13.
19:09:26,63: iTelex(23059): SeriellUmsetzInit: BusVerbPartner = 12, SerUmTicksProBit = 18
19:09:26,63: iTelex(23059): Anwahl intern 12 verbunden mit 12
19:09:26,65: iTelex(23060): TWI Einschaltquittung intern / kommend
19:09:26,65: iTelex(23060): ModusWechsel von 13 nach 14.
19:09:26,66: iTelex(23060): Socket Sendung: (7) 07 05 01 39 36 36 00 --> Res 7 SumAnz 0/00

Sehr ordentlich. 600 ms Wartezeit bis zum Empfang des ersten Paketes. Damit kann man arbeiten.

Ich vermute, dass nicht so viele Firmware-Version von diesem Problem betroffen sind. Sonst gäbt es viel mehr Probleme mit meinen Diensten.
Gehört die 915 nicht auch zu den Versionen, die Probleme mit einem zu langen Versions-Paket haben?

Fred, kannst du meine Analyse bestätigen?

[FredSonnenrein]

Hallo Detlef,

deine Beobachtung muss Zufall sein oder andere Hintergründe haben.
Ich kann mich nicht erinnern, in dem Bereich was umprogrammiert zu haben.

Ich kann daher nicht garantieren, dass es nur Version 915 betrifft. Ebenso nicht, dass das Phänomen überhaupt an der Version "hängt" oder eher durch lokale Einstellungen / lokale Eingenschaften der Internet-Anbindung des Anrufers begründet ist.

Was mich auch an den Protokoll-Mitschnitten wundert: Ich sehe dort die Protokollierung eines Anrufs AUF dem i-Telex, nicht vom i-Telex an einen Dienst... Welcher Zusammenhang besteht da?

Bitte entschuldige meine Verwunderung.

Viele Grüße,

Fred