No! The ttyI* devices just offer a similar communication interface, where all commands are started with AT. This makes it easy to reuse software that was written to communicate with a modem. Communication with a remote analog modem is not possible via the ttyI* devices! The real communication happens in digital, not analog form.
Only the ttyI* devices should be used. The cui* devices are created only for reasons of compatibility. Now that there is mgetty, there is not reason to use the cui* devices any longer. If they are used, locking will not work correctly (several programs could simultaneously attempt to use the same device).
With the option S14=3; for example "ATS14=3".
As usual, the same as with serial interfaces. Simply use /dev/ttyI* as the device, as the init string for the modem emulation you have to set the correct MSN or EAZ with "AT&Emsn/eaz".
It doesn't matter. The driver internally always uses the full speed that ISDN offers. This is also given in the connect string.
The maximum can be set by configuring ISDN_MAX at compile time. Currently, it is set to 64 by default, which means that up to 64 ttyI devices are supported.
Before dialing, you have to enter "AT&E123456" (if 123456 is your own MSN; with 1TR6 give the one-digit EAZ).
Probably you did not tell the modem emulation with
MSN to use. For example, use
AT&E123456; if your MSN is 123456.
Please also note that only one application using the ttyI* devices will receive a ring for a particular MSN. Which will ring is selected by a loop over all ttyI* devices. A device is selected based on whether its parameters match (protocol, MSN) and whether it is currently not involved with another call. Therefore it does not make sense for multiple applications to register for the same MSN via the ttyI* devices, unless you want to have load sharing between the applications.
You can. However, ISDN differentiates different services. All outgoing calls
with the ttyI* devices use the service "Digital Data", which is
incompatible with telephone or fax, so the call never gets through.
Change the service recognition with the
ATS18=1 command to audio, then
you can dial your telephone or fax.
There are several possible protocol parameters. There is HDLC, there is
X.75 and there are several possible block sizes with X.75. You can tell
the modem emulation about the block size with
used is a block size of 2048 byte:
If there is really no process using your modem emulation any more, try:
cu -l /dev/ttyI0 dir +++ ath0 ~.
Can happen when the partner cannot handle the large frames from i4l and simply closes the B channel during the transfer. Try making the frames smaller with AT&B512.
firstname.lastname@example.org wrote on 5 Dec 1996:
I had to use the following settings, otherwise I only had errors. # Prot protocol-parameter g packet-size 512 protocol-parameter g short-packets y protocol-parameter g window 7 protocol-parameter g remote-window 7 protocol-parameter v packet-size 512 Now with large packets I can get ca 7300 cps.Holger Burbach
email@example.com 5 Feb 1997 had another solution:
I have several XP users who poll without any problems. I did the following: First I set the send packet size for ttyI? to 1024 ("AT&B1024") and then set the packet size for the g protocol in UUCP: protocol-parameter g packet-size 2048 protocol-parameter g remote-packet-size 0 As I said, it works fine..