Dies ist die Homepage der "Rate Data Crew":
{urlnam}
. Dort bekommst die
neuesten Dateien mit den Geb{[uuml ]}hrenraten (die sich recht schnell
{[auml ]}ndern) oder kannst einen Blick auf die neuesten Nachrichten
werfen.
Es gibt f{[uuml ]}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{[uuml ]}r die dekodierten Dienstetypen in Deiner 'isdnlog.conf' angegeben hast ...
Aus Gr{[uuml ]}nden des Datenschutzes werden Telefonnummern des analogen Netzes nicht {[uuml ]}bermittelt, es sei denn, der Anrufer hat dies der Telekom ausdr{[uuml ]}cklich erlaubt (das ist kostenlos).
Die Teilnehmer mit einem ISDN-Anschlu{[szlig ]} m{[uuml ]}ssen andererseits ausdr{[uuml ]}cklich die {[Uuml ]}bermittlung der Nummer durch die Telekom verweigern oder beantragen, die {[Uuml ]}bermittlung auf Call-by-Call-Basis (CLIR) zu verweigern oder zu gestatten. Die Verweigerung bei Call-by-call ist kostenlos, die {[Uuml ]}bertragung bei Call-by-Call kostenpflichtig. Es scheint jedoch f{[uuml ]}r die Telekom extrem schwierig zu sein, das beim ersten Versuch richtig einzustellen. Wenn Du Wert auf die {[Uuml ]}bertragung der Caller ID legst, solltest Du sehr genau pr{[uuml ]}fen, ob alles richtig konfiguriert wurde.
Ja, bei Anrufen aus L{[auml ]}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 {[uuml ]}berwacht und die andere ist 'netzwerk-generiert' (durch die Telefongesellschaft). Wie der Name schon sagt wird die erste Nummer vom Benutzer bereitgestellt w{[auml ]}hrend die zweite vom Netzwerk {[uuml ]}bertragen wird. Die Bereitstellung einer Caller ID ist nur mit einer PBX {[uuml ]}ber eine Point-to-Point Konfiguration mit dem Feature "CLIP no screening" m{[ouml ]}glich.
Weil die ISDN-Karte, wie alle ISDN-Ger{[auml ]}te, separate Leitungen
f{[uuml ]}r das Senden und das Empfangen hat (RX und TX
Leitungen). Isdnlog m{[uuml ]}sste die Daten der empfangenden Leitung
lesen um die gew{[auml ]}hlte Nummer zu erkennen. Dies ist nicht
m{[ouml ]}glich, zumindest nicht f{[uuml ]}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{[auml ]}nger. Theoretisch ist es m{[ouml ]}glich, den gesamten D-Kanal mit nur einem Empf{[auml ]}nger (sogar mit dem ISAC) auszulesen; die D-Bits der RX-Leitung werden (etwas verz{[ouml ]}gert) auf die TX-Leitung kopiert, {[uuml ]}ber die die Zugriffskontrolle (Kollisionskontrolle) des S0-Busses stattfindet. Leider ist es mit dem ISAC nicht m{[ouml ]}glich, die echo bits im TA-Modus aus einem Register auszulesen.In den n{[auml ]}chsten Fragen findest Du vielleicht eine L{[ouml ]}sung.
Da gibt es mehrere M{[ouml ]}glichkeiten:
3 -- RX+ 2a ---------------{[bsol ]} ISDN 4 -- TX+ 1a -- open ------------ ISDN bus 5 -- TX- 1b -- open ------------ card 6 -- RX- 2b ---------------/Beachte bitte, da{[szlig ]} 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.
hisaxctrl {[lt ]}driver_id{[gt ]} 1 4 hisaxctrl {[lt ]}driver_id{[gt ]} 10 1 hisaxctrl {[lt ]}driver_id{[gt ]} 12 1
hessler@wi-inf.uni-essen.de
).
Du kannst 'xisdnload' benutzen. Clemens Perz
listperz@gwsnet.ttt.de
beschrieb am 06. Februar 1997 eine
weitere M{[ouml ]}glichkeit:
Auf Sunsite fand ich ein kleines Tool f{[uuml ]}r die Konsole namens netload und passte es f{[uuml ]}r die ISDN-Interfaces an. Damit kannst Du sehr leicht den aktuellen Verkehr auf der Leitung beobachten. Du findest es auf:{urlnam}
. Starte es einfach mitnetload isdnxx
.
Der Anrufer hat vermutlich das (teure) Feature CLIP (= Calling Line Identification Presentation, no screening) aktiviert, was bedeutet, da{[szlig ]} jede beliebige Telefonnummer {[uuml ]}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{[auml ]}uschen, die den Screening Indicator (Anzeige, da{[szlig ]} die {[uuml ]}bertragenen Nummern auf Korrektheit gepr{[uuml ]}ft werden) nicht auswerten - isdnlog (>=2.52) zeigt sowohl die korrekte als auch die vorgegebene Telefonnummer an. 'CLIP, no screening' wurde urspr{[uuml ]}nglich geschaffen um firmeninterne Rufnummern im {[ouml ]}ffentlichen Netz zu {[uuml ]}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{[ouml ]}here Instanz, die den Zugriff auf das Sound-Device koordiniert. Das k{[ouml ]}nnte NAS (Network Audio System) und rplay sein.
play anruf.au 2{[gt ]}/dev/null
). Warum erz{[auml ]}hlt mir ISDN dann: Can't start '/usr/local/bin/play anruf.au 2{[gt ]}/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{[uuml ]}hrbar (chmod +x):
{[num ]}!/bin/sh /usr/local/bin/play anruf.au 2{[gt ]}/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{[szlig ]}
mehr als x Minuten vergangen sind und das bewirkt einen kurzen
Blackout des Bildschirms.