* Klaus Heske
ich habe ein Problem mit isdnrep und eingehenden Anrufen und habe in den Archiven dazu leider nichts gefunden. [...] Wenn ich die Datei /var/log/isdn.log aber nach eingegangenen Anrufen durchgreppe, dann finde ich sie auch, das logging scheint also stattzufinden..
Ich habe das gleiche auf einer SuSE 8.2-Installation versucht (mit isdnrep -a -f /file/von/anderem/server/isdn.log) ->genau das gleiche..
Das Problem ist mit dem neuen isdnlog-4.66 behoben, welchen ich vor kurzem ins CVS bei isdn4linux.de eingepflegt habe. Ursache war der Betrieb der AVM B1 Karten an einem Anlangenanschluß hinter einer Telefonanlage. Beim Anlagenschluß (Punkt-zu-Punkt) ist die TEI auf 0 festgesetzt, so daß der Ansatz von isdnlog, eine eingehende Verbindung an der Broadcast-TEI 127 zu erkennen, hier nicht funktioniert. Der neue isdnlog bestimmt bei einer AVM B1 Karte (mit D2 Trace) die Richtung anhand der Ursprungsseite der Call Reference. In der vorliegenden Konfiguration ist es empfehlenswert in /etc/isdn/isdn.conf unter AREACODE nicht nur die Vorwahl sondern dahinter auch die Kopfrufnummer der Telefonanlage einzutragen, um vollständige eigene Rufnummern in der isdn.log zu erhalten.
Wenn ich mir /var/log/messages anschaue kriege ich bei eingehenden Anrufen neben den üblichen Informationen immer das hier:
<schnipp> Aug 15 14:36:14 faxserver isdnlog: Aug 15 14:36:14 * tei 0 calling +49 711/555, Stuttgart with +49 711/xxxxxx743, Stuttgart UNKNOWN ELEMENT 32: 80 [ ], length=1 -- complete frame ignored! <schnapp>
Diese Meldung hat nichts mit dem eigentlichen Problem zu tun. Wie hier in letzter Zeit bereits mehrfach zu lesen war, sendet die Telefonalage in einer D-Kanal-Nachricht ein unbekanntes Informationselement, dass isdnlog bislang zu dieser Ausgabe veranlasste. Der neue isdnlog unterstützt Codeset-Umschaltungen und sollte dies nur noch für unbekannte Informationselemente im durch ITU und ETSI genormten Codeset 0 tun und unbekannte Informationselemente in anderen Codesets stillschweigend ignorieren. Das zitierte Informationselement 0x32 im Codeset 5 entstammt übrigens einer Norm für private Telefonnetze (u. a. ECMA-143) und gibt die "Party Category" an, die hier unbekannt ist. Andere mögliche Werte wären Nebenstelle, Operator oder Notruf. Gruß Tobias -- Tobias Becker E-Mail tobiasb@talypso.de PGP 0xD06BB70D * Und erfahrene Menschen sagen, daß derjenige, der zu viel sieht und zu viel weiß, ähnlich wie der, der zu wenig sieht und zu wenig weiß, leicht vom richtigen Weg abkommt und untergeht. * Stefan Chwin *