Channel bundling is currently supported by isdn4Linux in two variations:
ibod
- see question
2channel_mpppconfig for more
details.
Raw bundling works similarly to raw IP, only with several channels. Therefore, it has the theoretical advantages and disadvantages of raw IP. Raw bundling requires a network interface for each channel that is used. One network interface, the so-called master interface, controls the establishment and breaking of connections. For each further channel, an additional so-called slave interface is configured, that is automatically switched on by the master interface.
The master interface is created as usual with
isdnctrl addif master interface
isdnctrl addslave master interface slave interface
Raw bundling has all the advantages and disadvantages of raw IP. Compared to MPPP, raw bundling has the advantage that isdn4linux itself can open and close the needed slave channels. Unfortunately raw bundling still has problems with transfer rates. See the further questions below.
MPPP or MP or MPP (Warning: MP is also an acronym for 'Multi Processor') stands for Multi Point to Point and means bundling of several channels to one logical stream. It's a variation of the normal syncPPP. Accordingly, it inherits all its advantages and disadvantages. Just for your information: ipppd does MPPP according to RFC 1717, instead of the newer RFC 1990 (MLP).
In contrast to raw bundling only one net interface is needed as interface to the ipppd, since the ipppd handles all its channels by itself. Incoming data is distributed round-robin by the ipppd on all available channels. These channels do not necessarily have to be ISDN channels. In theory, modem connections could be mixed with ISDN channels. However, here we only cover ISDN channels.
A disadvantage is that the slave channel has to be activated "manually". ipppd cannot by itself turn the slave channel on and off as it needs to. The normal automatic functions of ipppd are either unreliable (auto hangup) don't work at all (auto dial). This is not true for the other encapsulations. The transfers rates are very good (ca. 30 KB/s with 4 channels).
First ensure that support for MPPP has been switched on for compilation of your ISDN modules. Then define a (normal) interface for ipppd (e.g. "isdnctrl addif ippp0", etc). This interface will be used as your master interface. Then you must configure a slave device for every additional channel (e.g. "isdnctrl addslave ippp0 <slave_interface>", configure slave_interface, etc - see the i4l manual for more). To enable MPPP negotiation, ipppd must be called with the "+mp" option and both devices have to be given to ipppd. Please note that the name of both devices has to start with "ippp".
To use channel bundling you must first activate the 'master' or initial call. Now you can add the slave channels with the command:
isdnctrl addlink device
isdnctrl removelink device
Please also note, that the slave device has to be in dialmode auto
for
this to work. For manual control, use
isdnctrl dial slave
isdnctrl hangup slave
With syncPPP, there is no automatic activation of slave devices, they have to
be added and removed. However, there is the program ibod
available,
which can do this automatically. Have a look at:
http://www.compound.se/ibod.html
or (for a version extended by Karsten Keil):
http://www.suse.de/~kkeil/xibod/
In the file etc/rc.isdn.syncppp.MPPP
in the isdn4k-utils package you
can find a sample script (unfortunately missing in some i4l versions).
Please note that your Internet Provider has to allow you to make use of these features. Also, there may be a limit on how many channels you are allowed to open at the same time. It could be that all links are dropped when you exceed this limit.
You forgot to compile MPPP/RFC1717 support into the ISDN Subsystem. Recompile with this option enabled.
This is a pecularity of ipppd. It tries to set MTU even for slave devices, and the kernel can not find a corresponding network device. You can safely ignore this information message, MPPP should work nevertheless.
Master and slave device are fully independent of each other, except for using the same network device to deliver packets. Setting up multiple number for master and slave devices will result in synchronized dialout (to the same number). Therefore it is best to give the slave device no number by default and set up the slave with the same number as the master in some ip-up script.
Well, this is a tough one, due to technical limits. Even if isdn4linux freed a B-channel, the exchange would not repeat the setup call. Therefore, the phone would not ring. The phone only signals a second incoming phone call if you are on the phone with another call that could be suspended.
One option would be that isdn4linux frees one B-channel, then takes the call,
and transfers it to the phone via ECT (explicit call transfer); however, this
feature requires proprietary (unknown) protocol extensions, and is usually
only available behind large private exchanges - therefore not implemented
in isdn4linux.
Another option is that isdn4linux frees one B-channel, takes the call, then
suspends it. However, the user would have to know to resume it without any
phone ringing.
The most sensible option is that you handle it will a phone application
making use of isdn4linux. Possibly ant-phone could be used for such a purpose:
http://www.antcom.de/