23. isdnlog: Isdnlog

23.1 isdnlog_rates: Where do I get the latest rate information?

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: rates4linux-users-request@lists.sourceforge.net (send "help" in your subject to get instructions). To write to the mailing list, send an email to: rates4linux-users@lists.sourceforge.net.

23.2 isdnlog_servicetype: Can I see the service type from an incoming call in the output from isdnrep?

Andreas Kool 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" ...

23.3 isdnlog_callerid1: Why don't I always receive from the German Telekom the number of a caller ("Caller ID")?

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.

23.4 isdnlog_callerid2: Do I receive the Caller ID from foreign calls (German Telekom)?

Yes, with calls from countries that don't view Caller ID quite as strictly as does Germany (e.g. USA, Canada).

23.5 isdnlog_spoofcallerid: I've heard that actually two Caller IDs are transmitted?

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".

23.6 isdnlog_betterlogging: Why doesn't isdnlog record the number dialed by my other ISDN devices, since it records the charges?

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 keil@isdn4linux.de 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.

23.7 isdnlog_reversedcard: How can I get isdnlog to also show the telephone numbers for other ISDN devices?

There are several possibilities.

• COLP: First, the German Telekom offers the service COLP (Connected Line Identification Presentation, ca. DM 10 per month per basic line) that returns all data sent. This can then be read by isdnlog (=2.52) from the TX line.
• Reversed card/dual mode: Alternatively, isdnlog offers the possibility to work with a second "re-poled" ISDN card. "re-poled" means that the RX line is connected to the TX connection of the card; the RX line of the card should not be connected to any line! (even if other documents might tell you something else). Because of this setup, this ISDN card cannot be used for anything else. This is called a reversed card, or the dual mode. The whole thing looks something like this:

        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).
• HFC cards: some HFC-PCI based cards allow a special feature where one of the B channels can be sacrificed in exchange for reading the complete D channel protocol - with just one single card. This is also supported by isdn4linux. Set the HFC card in the following way:

  ---

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

  ---

  You have to give isdnlog the command line option '-1' so that it makes use of the HFC option. Please note that a plain HFC-S does not work for hardware reasons, it has to be a newer one. If your card works with Hisax type 35 or 37, then it should work. Please also note that there is no known card for logging on a PRI interface in this way (also, the PRI interface is point-to-point, therefore only one device can be connected).
• PBX: A third (theoretical) possibility exists for those who have their own PBX to which the other devices are connected. If the PBX can protocol all outgoing calls, this can be read (usually over a serial port). There is a reason why isdnlog has not support for this until now. To evaluate this data, isdnlog has to be able to access the date immediately after the RELEASE COMPLETE, before any new data is sent on the D channel. The PBXs tested up to now have all been too slow (in particular the widely used ISTEC). The only possibility is to combine the data afterwards. But then there are problems with synchronizing the different times. Whoever want to attempt to do this is very welcome.

23.8 isdnlog_rategraphic: How can I display the data transfer rates graphically?

You can use "xisdnload". Clemens Perz listperz@gwsnet.ttt.de on 6 Feb 1997 knew of another possibility:

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:

ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz

Simply start with netload isdnxx.

23.9 isdnlog_2callerid: Isdnlog (=2.52) shows for a caller two telephone numbers! Which one is correct?

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?".

Andreas Kool 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.

23.10 isdnlog_soundbusy: I've set up a script to play sound per cat on /dev/sound or some other device. When several events occur, then there is an error: 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.

23.11 isdnlog_noshell: Isdnlog should call a program with redirected output (e.g. 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

23.12 isdnlog_blankscreen: When dialing out, the screen goes momentarily black?

This may happen when you start isdnlog with the options -t1 or -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.

23.13 isdnlog_nologging: Isdnlog does not log any incoming call for me?

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.

23.14 isdnlog_enoughdata: How can I check whether isdnlog receives enough information from the kernel drivers?

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.

23.15 isdnlog_database: How can I set up isdnlog with database support?

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.