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" ...
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
keil@temic-ech.spacenet.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.See the next questions for a possible solution.
There are two possibilities. 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
Alternatively, the next version of isdnlog (currently 2.52) will offer the possibility to work with a second "re-poled" Teles card, i.e. 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! Because of this setup, the Teles card cannot be used for anything else. 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 ---------------/
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 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 welcome (I'll make the logs from my
Ackermann Euracom available - Matthias Heßler
hessler@wi-inf.uni-essen.de).
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