,---------[ teledat.sourceforge.net ]---------- | Autor: Felix Schwarz | Webseite: teledat.sourceforge.net | Lizenz: GNU Free Documentation License 1.1 oder neuere (s.u.) | |--------- Changelog --------- | 20.07.03 fs Anpassung der Protokollnummerierung (v3.0 und v3.1) | 13.03.03 fs Analyse an Hand einer Fritz!X PC v2 und dem reinen v3-Protokoll | 24.02.03 fs Dokument erstellt | `--------- -------------------------------------------------------------------------------- Vorbemerkung: Die Meldung eines Anrufers ist auch im reinen v3.1-Protokoll möglich, jedoch muss es mindestens eine spezielle Sequenz geben, damit die Anlage entspr. Benachrichtigungen verschickt. Analyse einer Anrufermeldung im reinen v3.1-Protokoll mit einer Fritz!X v2: # Nebenstellen 2,3,4 angerufen, unbekannte Rufnummer. -> 7E FF A0 00 00 00 00 00 00 00 00 00 21 21 21 (d1-4) (CRC) 7E a1-a4: 1 Byte (0x21), ist in der Löschbestätigung nicht mehr vorhanden (d1)-(d4) je 20 Byte, stellen jeweils die Nebenstellen 1-4 dar. Bei jeder Nebenstelle erscheint die Nummer des Anrufenden (wenn Rufnummer nicht vom Anrufer unterdrückt wurde). Sollte die Nummer kürzer als 20 Stellen sein, wird sie durch ein Nullbyte und folgenden Byte-Schrott abgeschlossen. Bei unbekannten Nummern ist gleich die erste Stelle ein Nullbyte. Sollten noch andere Anrufe gleichzeitig signalisiert werden, kann man dies an den unterschiedlichen Nummern sehen. Prinzipbedingt kann auf einer analogen Leitung (und die Nebenstellen sind nichts anderes) nur ein Signal weitergeleitet werden, bei mehreren gleichzeitigen Anrufen auf einer bestimmten Nebenstelle "gewinnt" daher der erste Anruf. Im Gegensatz zur gespeicherten Anrufermeldung gibt es hier keine Felder für das Datum des Anrufs (was ja auch überflüssig ist, da es eine Live-Meldung ist - über das Fehlen der zus. Felder lässt sich auch ein Live-Anruf leicht ermitteln). Zu beachten ist weiterhin, dass u.U. diese Meldung am Anfang mehrfach auftaucht, wobei in den späteren Meldungen mehr Nebenstellen angesprochen werden. Hier gibt es scheinbar Timing-Probleme, so dass von Anfang an nicht alle Nebenstellen dabei sind. Gleiches gilt auch für das Ende der Verbindung, wenn zunächst nur einzelne Nebenstellen wegfallen. Wenn ein Anrufer ergebnislos auflegt, sendet die Anlage: ->7E FF A1 (a1) (a2) (a3) (a4) (CRC) 7E <-7E FF E1 00 C6 35 7E a1-4 je 2 Byte - jede Nebenstelle, die vorher klingelte: 0x09 0x34, für die stillen Nebenstellen 0x00 0x00 Dies ist Meldung, dass ein Anrufer aufgelegt hat, über die Signalisierung kann man herausfinden, welche Nebenstellen davon betroffen sind. Anschließend wird eine neuer Statusbericht (0xff 0xa0) gesendet, der nach dem Auflegen des letzten Anrufers wie folgt aussieht: ->7E FF A0 00 00 00 00 00 00 00 00 00 00 00 00 00 (a) 00 (a) 00 (a) 00 (a) (CRC) 7E <-7E FF E0 00 DF ED 7E (a) 19 Byte, Schrott (wichtig ist 0x00 davor) Legt man die gleichen Daten an wie oben (rein von der Byte-Anzahl passt es perfekt), könnte es eine Übersichts-Meldung sein, welche Kanäle noch besetzt sind - das ist aber gar keiner, weil der Anrufer ja soeben aufgelegt hat... -------------------------------------------------------------------------------- altes Zeugs: Meldung eines Anrufs Anlage sendet: 7E 00 02 FF 03 08 01 01 05 A1 04 03 80 90 A3 18 01 89 6C ^^ 0C 21 83 (1) 70 09 C1 (2) [7D] 02 91 81 (3) 7E Antwort: ??? Bemerkungen: (1) (in diesem Fall 10 Byte) Die Nummer des Anrufers inkl. Deutschland-Vorwahl, allerdings ohne führende Null, bei Rufnummernunterdrückung fehlte dieses Feld völlig und die drei Bytes vorher waren 02 00 A3. (2) (in diesem Fall 8 Byte) angerufene MSN (3) (2 Byte) CRC Man beachte das 0x0C bzw. 0x09 vor (1) und (2) - dieses Byte scheint die Länge der Rufnummer anzugeben (+ die 2 bzw. 1 Byte davor) Die 0x89 (oben markiert) ist nicht bei jedem Anruf gleich (ist auch häufiger 0x8A) Entgegen meiner ersten Vermutungen ist die angerufene Nebenstelle nicht im Request kodiert! Ev. wird diese Information nur auf Grund der in der Konfigurations-Software ohnehin vorhandenen Infos ermittelt, was mir aber nicht besonders sinnvoll erscheint, immerhin müsste die Anrufermeldung auch kommen können, ohne dass vorher die Einstellungen der MSNs abgerufen wurden. Überprüfung: Anlage so konfigurieren, dass bestimmte Nummern nicht auf allen Nebenstellen signalisiert werden, neue Windows-Installation, frisch die AVM- Software aufspielen, direkt in den "Telefonie"-Abschnitt gehen und anrufen. Im Log dürfte es keinerlei Informationen über die MSNs geben, das Anrufermodul wird aber vermutlich trotzdem die richtigen Nebenstellen anzeigen Eine Kodierung der ISDN-Dienstart scheint mir sinnvoll (z.B. bietet Fritz!Fax die Option, die Dienstart auszuwerten). todo: Anruf auf eine Anlage mit einer Nummer, die ings. nicht 10 Stellen hat, um die Längenangabe zu überprüfen <-7E 00 00 F1 7F 7D 5E 12 7E ->7E 00 00 F1 73 12 D8 7E ->7E 00 00 E7 01 84 27 91 7E ->7E 00 00 E1 01 7D 5E 2B 1F 7E ->7E 00 02 DB C4 5C 08 01 D6 01 1E 02 82 88 A8 30 7E ->7E 00 00 DB 01 5E FD CB 7E Anlage sendet Informationen über den Anrufer, die Nebenstellen im v3.1-Protokoll (Multiframe), sehr ähnliches Format wie beim Abruf der aufgelaufenen Anrufer nach der Identifizierung. 7E FF A0 00 00 02 02 00 00 00 00 (a1-a4) (b1) (b2) (b3) (b4) (c) 7E (a1)-(a4) je 1 Byte, bei normalen Anrufen steht hier aber immer 0x21 (für jede angerufene Nebenstelle 1 Byte). Ev. handelt es sich hierbei um die ISDN-Dienstekennung (Fax, Anruf, Datentransfer...). 'analoger Telefonanruf' entsprechen. (b1)-(b4) je 32 Bytes, stellen jeweils die Nebenstellen 1-4 dar. Bei jeder Nebenstelle erscheint die Nummer des Anrufenden, die bis zu 32 Stellen lang sein könnte (10 sind verifiziert, 20 wahrscheinlich, alles darüber wäre zwar plausibel, ansonsten jedoch Spekulation). Sollte die Nummer kürzer als 32 Stellen sein, wird sie durch ein Nullbyte und folgenden Byte-Schrott abgeschlossen. Bei unbekannten Nummern ist gleich die erste Stelle ein Nullbyte. Bei jeder Nebenstelle, an die der Klingelton gesandt wurde, wird auch die Anrufernummer angezeigt. (c) 2 Byte CRC Software antwortet mit Löschbefehl 7E FF E0 00 DF ED 7E ->7E 00 02 DB D0 70 08 01 D8 01 1E 02 82 88 D2 DC 7E ->7E 00 00 DB 01 72 93 20 7E ->7E 00 00 DF 01 38 AC AE 7E (snip - normaler keep-alive) ->7E 00 00 DB 01 74 A5 45 7E ->7E 00 02 E1 A8 86 08 01 01 4D 08 02 80 90 C6 61 7E ->7E 00 02 E7 44 8C 08 01 01 4D 08 02 80 90 0C F6 7E ->7E 00 02 DB D2 74 08 01 D8 4D B0 FA 7E ->7E 00 00 E7 01 8E 7D 5D 3E 7E ->7E 00 00 E1 01 88 92 8D 7E ->7E C0 7D 5E FF A1 00 00 90 34 00 00 00 00 98 EC 7D 5E A0 63 7E <-7E C0 7D 5E FF E1 00 C6 35 7D 5E 25 E9 7E Die Anlage sendet nochmal ein Datenpaket im v3.1-Protokoll, ev. Auflegen? 7E FF A0 00 00 02 02 00 00 00 00 (a1-a4) (b1) (b2) (b3) (b4) (c) 7E (a1)-(a4) je 1 Byte, immer 0x00, vorher 0x21 (b1)-(b4) je 32 Bytes, beim ersten Mal stand hier die Telefonnummer, jetzt nur noch Nullen (c) 2 Byte CRC ->7E 00 00 DB 01 76 B7 66 7E <-7E C0 7D 5E FF E0 00 DF ED 7D 5E 11 6A 7E <-7E 20 FF 03 AC 08 7E ->7E 20 FF 03 00 16 9F 7E ->7E 00 02 DF 01 39 53 86 7E ->7E 00 02 F1 01 01 B8 28 7E <-7E 00 02 F1 01 01 B8 28 7E ->7E 00 02 E1 01 89 6D A5 7E ->7E 00 02 E7 01 8F 82 16 7E -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ,---------- [ COPYING ] ----------- | Permission is granted to copy, distribute and/or modify this document | under the terms of the GNU Free Documentation License, Version 1.1 or | any later version published by the Free Software Foundation; with no | Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. A | copy of the license can be obtained under | http://www.gnu.org/licenses/fdl.txt `----------------------------------