24. isdnlog: Isdnlog

24.1 isdnlog_rates: Wo bekomme ich die aktuellsten Gebühreninformationen?

Dies ist die Homepage der "Rate Data Crew": http://rates4linux.sourceforge.net/. Dort bekommst die neuesten Dateien mit den Gebührenraten (die sich recht schnell ändern) oder kannst einen Blick auf die neuesten Nachrichten werfen.

Es gibt für diesen Bereich auch eine Mailingliste. Du abonnierst diese durch eine Email mit dem Subject "subscribe" an: rates4linux-users-request@lists.sourceforge.net (mit "help" im Subject bekommst Du Instruktionen). Du schreibst an die Mailingliste mittels Email an: rates4linux-users@lists.sourceforge.net.

24.2 isdnlog_servicetype: Kann ich den Dienstetyp eines ankommenden Anrufes in der Ausgabe von isdnrep sehen?

Andreas Kool akool@Kool.f.EUnet.de schrieb am 03. Dezember 1996:

Indirekt in isdnrep, ja -- sobald Du ein Alias für die dekodierten Dienstetypen in Deiner 'isdnlog.conf' angegeben hast ...

24.3 isdnlog_callerid1: Warum bekomme ich nicht immer die Nummer eines Anrufers ('Caller ID') durch die Deutsche Telekom übermittelt?

Aus Gründen des Datenschutzes werden Telefonnummern des analogen Netzes nicht übermittelt, es sei denn, der Anrufer hat dies der Telekom ausdrücklich erlaubt (das ist kostenlos).

Die Teilnehmer mit einem ISDN-Anschluß müssen andererseits ausdrücklich die Übermittlung der Nummer durch die Telekom verweigern oder beantragen, die Übermittlung auf Call-by-Call-Basis (CLIR) zu verweigern oder zu gestatten. Die Verweigerung bei Call-by-call ist kostenlos, die Übertragung bei Call-by-Call kostenpflichtig. Es scheint jedoch für die Telekom extrem schwierig zu sein, das beim ersten Versuch richtig einzustellen. Wenn Du Wert auf die Übertragung der Caller ID legst, solltest Du sehr genau prüfen, ob alles richtig konfiguriert wurde.

24.4 isdnlog_callerid2: Erhalte ich die Caller ID bei ausländischen Anrufen?

Ja, bei Anrufen aus Ländern, die das mit der Caller ID nicht ganz so streng sehen wie Deutschland (z.B. USA, Canada).

24.5 isdnlog_spoofcallerid: Ich habe gehört, daß in Wirklichkeit zwei Caller IDs übertragen werden?

Richtig, die eine ist 'benutzer-generiert' und nicht überwacht und die andere ist 'netzwerk-generiert' (durch die Telefongesellschaft). Wie der Name schon sagt wird die erste Nummer vom Benutzer bereitgestellt während die zweite vom Netzwerk übertragen wird. Die Bereitstellung einer Caller ID ist nur mit einer PBX über eine Point-to-Point Konfiguration mit dem Feature "CLIP no screening" möglich.

24.6 isdnlog_betterlogging: Wieso zeichnet isdnlog die Nummern, die mit meinen anderen ISDN-Geräten gewählt werden, nicht auf, obwohl es die Kosten aufzeichnet?

Weil die ISDN-Karte, wie alle ISDN-Geräte, separate Leitungen für das Senden und das Empfangen hat (RX und TX Leitungen). Isdnlog müsste die Daten der empfangenden Leitung lesen um die gewählte Nummer zu erkennen. Dies ist nicht möglich, zumindest nicht für die Teles-Karten, wie Karsten Keil keil@isdn4linux.de am 12. Februar 1997 schrieb:

Dies ist der Fall bei allen Karten mit 1 Siemens ISAX; er hat (und braucht) nur 1 Sender und 1 Empfänger. Theoretisch ist es möglich, den gesamten D-Kanal mit nur einem Empfänger (sogar mit dem ISAC) auszulesen; die D-Bits der RX-Leitung werden (etwas verzögert) auf die TX-Leitung kopiert, über die die Zugriffskontrolle (Kollisionskontrolle) des S0-Busses stattfindet. Leider ist es mit dem ISAC nicht möglich, die echo bits im TA-Modus aus einem Register auszulesen.

24.7 isdnlog_reversedcard: Wie erreiche ich, daß isdnlog auch die Nummern zeigt, die von anderen ISDN-Geräten gewählt werden?

Da gibt es mehrere Möglichkeiten:

• COLP: Erstens bietet die Deutsche Telekom den Service COLP (Connected Line Identification Presentation) für ca. DM 10 pro Monat an, der alle gesendeten Daten zurück sendet. Diese können dann von isdnlog von der TX-Leitung ausgelesen werden.
• Umgepolte Karte/Dualmodus: Alternativ bietet isdnlog die Möglichkeit, mit einer zweiten, "umgepolten" ISDN-Karte zu arbeiten. 'Umgepolt' bedeutet in diesem Fall, daß die RX-Leitung mit dem TX-Anschluss der Karte verbunden wird; die RX Leitung der Karte sollte nirgends angeschlossen (stillgelegt) werden (selbst wenn andere Doks etwas anderes sagen)! Aufgrund dieser Schaltung kann diese ISDN-Karte für sonst nichts benutzt werden. Die ganze Schaltung sieht dann etwa so aus:

        3 -- RX+ 2a ---------------\
  ISDN  4 -- TX+ 1a -- open         ------------  ISDN
  bus   5 -- TX- 1b -- open         ------------  card
        6 -- RX- 2b ---------------/ 
  

  Beachte bitte, daß dies nur funktioniert, wenn die zweite Karte einen ISAC-Chip besitzt (z.B. alte Teles-Karten, Fritz! classic), da dabei ein spezieller Bug/Feature dieses Chips genutzt wird. Alle anderen Karten, wie IPAC-Karten (z.B. ELSA QS1000pro), funktionieren nicht in der Rolle der umgepolten Karte.
• HFC-Karten: Einige HFC-PCI-Karten verfügen über ein spezielles Feature. Bei ihnen kann man einen B-Kanal opfern und dafür das gesamte D-Kanal-Protokoll auslesen - alles mit einer Karte. Dies wird auch von ISDN4LINUX unterstützt. Die HFC-Karte sollte dann wie folgt konfiguriert werden:

  ---

  hisaxctrl <driver_id> 1 4
  hisaxctrl <driver_id> 10 1
  hisaxctrl <driver_id> 12 1
  

  ---

  Dem isdnlog muss die Kommandozeilenoption '-1' übergeben werden, daßer die HFC-Option nutzt. Beachte bitte, daß ein einfacher HFC-S aus hardwaretechnischen Gründen nicht genügt, es muss ein neuerer sein. Wenn Deine Karte mit dem HiSax-Typ 35 oder 37 läft sollte es funktionieren.
• TK-Anlage: Eine dritte (theoretische) Möglichkeit besteht für die Besitzer einer eigenen TK-Anlage, an die die anderen Geräte angeschlossen sind. Wenn die TK-Anlage alle ausgehenden Gespräche protokollieren kann, so kann man das auslesen (üblicherweise über einen seriellen Anschluß). Es gibt einen Grund, warum isdnlog dies bisher nicht unterstützt. Zur Auswertung dieser Daten muss isdnlog sofort nach RELEASE COMPLETE darauf zugreifen können, bevor irgendwelche anderen Daten über den D-Kanal geschickt werden. Die bisher getesteten Anlagen waren dazu alle zu langsam (besonders die verbreitete ISTEC). Die einzige Möglichkeit wäre, die Daten hinterher zusammenzufügen. Aber da gibt es wiederum Probleme mit den verschiedenen Zeitangaben. Wer auch immer einen Versuch damit wagen will ist willkommen (Ich werde die Logs meiner Ackermann Euracom zur Verfügung stellen - Matthias Hessler hessler@wi-inf.uni-essen.de).

24.8 isdnlog_rategraphic: Wie kann ich die Transferraten grafisch anzeigen?

Du kannst 'xisdnload' benutzen. Clemens Perz listperz@gwsnet.ttt.de beschrieb am 06. Februar 1997 eine weitere Möglichkeit:

Auf Sunsite fand ich ein kleines Tool für die Konsole namens netload und passte es für die ISDN-Interfaces an. Damit kannst Du sehr leicht den aktuellen Verkehr auf der Leitung beobachten. Du findest es auf: ftp://ftp.region.trier.de/pub/unix/linux/sources/ network/isdn/netload-0.92.isdn.tar.gz. Starte es einfach mit netload isdnxx.

24.9 isdnlog_2callerid: Isdnlog (=2.52) zeigt bei einem Anrufer zwei Telefonnummern an! Welche davon ist korrekt?

Der Anrufer hat vermutlich das (teure) Feature CLIP (= Calling Line Identification Presentation, no screening) aktiviert, was bedeutet, daß jede beliebige Telefonnummer übertragen werden kann. Sieh nach bei der Frage isdnlog_spoofcallerid.

Andreas Kool akool@Kool.f.EUnet.de schrieb am 26. Januar 1997:

Jedenfalls kannst Du nur Software/Anlagen täuschen, die den Screening Indicator (Anzeige, daß die übertragenen Nummern auf Korrektheit geprüft werden) nicht auswerten - isdnlog (>=2.52) zeigt sowohl die korrekte als auch die vorgegebene Telefonnummer an. 'CLIP, no screening' wurde ursprünglich geschaffen um firmeninterne Rufnummern im öffentlichen Netz zu übertragen.

24.10 isdnlog_soundbusy: Ich habe ein Script erstellt um Sound mit cat auf /dev/sound oder einem anderen Gerät abzuspielen. Wenn einige Ereignisse gleichzeitig geschehen erhalte ich eine Fehlermeldung: Can't open output file '/dev/sound': Device or resource busy.

Auf das Sound-Device kann nur jeweils ein Prozess zugreifen. Du brauchst eine höhere Instanz, die den Zugriff auf das Sound-Device koordiniert. Das könnte NAS (Network Audio System) und rplay sein.

24.11 isdnlog_noshell: Isdnlog soll ein Programm mit umgeleiteter Ausgabe aufrufen (z.B. play anruf.au 2>/dev/null). Warum erzählt mir ISDN dann: Can't start '/usr/local/bin/play anruf.au 2>/dev/null' with execvp()?

Weil isdnlog keine (Bourne-)Shell ist ;-). Isdnlog kann nur echte Programme starten. Schreibe einfach ein kleines Script und mach es ausführbar (chmod +x):

#!/bin/sh
/usr/local/bin/play anruf.au 2>/dev/null

24.12 isdnlog_blankscreen: Bei der Hinauswahl wird der Bildschirm kurze Zeit dunkel?

Das kann passieren, wenn Du isdnlog mit der Option -t1 oder -t2 startest, denn dann wird die Zeit mit der digitalen Vermittlungsstelle abgeglichen. Der Bildschirmschoner denkt, daß mehr als x Minuten vergangen sind und das bewirkt einen kurzen Blackout des Bildschirms.