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
.
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 ...
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.
Ja, bei Anrufen aus Ländern, die das mit der Caller ID nicht ganz so streng sehen wie Deutschland (z.B. USA, Canada).
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.
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.In den nächsten Fragen findest Du vielleicht eine Lösung.
Da gibt es zwei Möglichkeiten: 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.
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! 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-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.
Eine dritte (theoretische) Möglichkeit besteht für die Besitzer einer eigenen PBX an die die anderen Geräte angeschlossen sind. Wenn die PBX 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
).
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 mitnetload isdnxx
.
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.
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.
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
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.