This is the homepage of the rate data crew:
http://sourceforge.net/projects/rates4linux. There you
can download the latest rate files (which change very frequently),
or have a look at the latest rate news.
There is also a mailing list available for this kind of stuff. Subscribe
by sending an email with subject "subscribe" to:
(send "help" in your subject to get instructions).
To write to the mailing list, send an email to:
akool@Kool.f.EUnet.de wrote on 3 Dec 1996:
Indirectly in isdnrep, yes -- as soon as you enter an alias for the decoded service types in your "isdnlog.conf" ...
For data privacy reasons, telephone numbers from the analog network are not transmitted unless the caller has explicitly allowed the Telekom to do so (costs nothing).
Those with an ISDN connection, on the other hand, must explicitly deny permission for the Telekom to transmit the number, or apply to be able to do this on a call-by-call basis (CLIR). Call-by-call denial is free; call-by-call transmission costs extra. However, it seems to be very difficult for the Telekom to configure this correctly on the first try. If you depend on the transmission of Caller ID, you should check closely that everything is configured correctly.
Yes, with calls from countries that don't view Caller ID quite as strictly as does Germany (e.g. USA, Canada).
That's right, there's one that is "User-Provided, not screened", and the other is "Network-Provided" (from the telephone company). As the name says, the first one is provided by the user, whereas the second one is transmitted by the network. Providing a caller ID is only possible for a PBX connected in Point-to-point configuration with the feature "CLIP no screening".
Because the ISDN card, like all ISDN device, has separate lines for
sending and receiving (RX and TX lines). Isdnlog has to read data
from the receiving line to learn the number dialed. This isn't possible,
at least for the Teles cards, as Karsten Keil
wrote on 12 Feb 1997:
This is the case for all cards with 1 Siemens ISAX; it has (and needs) only 1 sender and 1 receiver. Theoretically, it's possible to read the entire D channel with just one receiver (even with the ISAC); the D bits from the RX line are copied (somewhat delayed) to the TX line, over which the access control (collision recognition) of the SO bus takes place. Unfortunately with the ISAC it's not possible to read the echo bits in TA mode from a register.See the next questions for a possible solution.
There are several possibilities.
3 -- RX+ 2a ---------------\ ISDN 4 -- TX+ 1a -- open ------------ ISDN bus 5 -- TX- 1b -- open ------------ card 6 -- RX- 2b ---------------/Please note that this only works when the second card is an ISAC based cards (e.g. old Teles cards, Fritz! classic), since it requires a special bug/feature of that chip. All other cards, like IPAC based cards (e.g. ELSA QS1000pro) will not work in the role of a re-poled card. Please note that this will only work on the standard BRI interface, since for the more expensive PRI interface no card is available which can be used (PRI is a point-to-point connection anyway).
hisaxctrl <driver_id> 1 4 hisaxctrl <driver_id> 10 1 hisaxctrl <driver_id> 12 1
You can use "xisdnload". Clemens Perz
firstname.lastname@example.org on 6 Feb 1997 knew of another
On Sunsite I found a little tool for the console called netload, and apapted it for the ISDN interfaces. With it you can quite easily see the current traffic on the line. It can be found at:
Simply start with
The caller has most likely activated the (costly) feature CLIP (= Calling Line Identification Presentation, no screening), which means any telephone number can be transmitted. See the question "I've heard that actually two Caller IDs are transmitted?".
akool@Kool.f.EUnet.de wrote on 26 Jan 1997:
In any case, you can only fool software/PBXs that do not evaluate the screening indicator - isdnlog with version 2.52 shows both the correct *and* the faked telephone number. 'CLIP, no screening' was actually designed for transmitting internal company numbers in the public network.
Can't open output file '/dev/sound': Device or resource busy
Only one process at a time can access the sound device. You need an upper instance that coordinates access to the sound device. NAS (network audio system), and rplay can be used for this.
play anruf.au 2/dev/null). Why does ISDN tell me
Can't start '/usr/local/bin/play anruf.au 2/dev/null' with execvp()?
Because isdnlog is not a (Bourne) shell ;-) Isdnlog can only start real programs. Just write a little script for it and make it executable (chmod +x):
#!/bin/sh /usr/local/bin/play anruf.au 2/dev/null
This may happen when you start isdnlog with the options
-t2, then the time is synchronized with the digital
switching station. The screen saver thinks that more than x minutes have
passed, which causes a short blackout of the screen.
Please verify whether your setup complies with the restrictions given in the isdnlog man page:
Isdnlog only works with the HiSax isdn driver. Other cards with their own driver are not supported. Additionally you need to enable d-channel logging (you can use "hisaxctrl <DriverId> 1 4" to do that, e.g. "hisaxctrl line0 1 4"). Isdnlog can only log outgoing calls that originate from your isdn card, and incoming calls. To get information about outgoing calls from other isdn devices (e.g. telephones), you need a second Teles isdn card, with crossed lines. Such a card is not usable for communicating, but can log outgoing calls from any device.
See also question isdnlog_reversedcard for using two ISDN cards for logging.
First stop isdnlog (e.g. "killall isdnlog"), then run "cat /dev/isdnctrl0". When you trigger some activity on the isdn line (e.g. by initiating an incoming call) you should see lines starting with "HEX:" or "D2:" in the output of the cat command. If these lines are missing then check your configuration of the kernel drivers.
You have to rebuild isdnlog for this. You can find some instructions (in German) on: http://lists.suse.com/archive/suse-isdn/2005-May/0043.html.