22. callback: Callback

22.1 callback_delay: An incoming call is rejected by i4l. i4l then calls back. The reject is not recognized by the other side which keeps on dialing to i4l.

Most problems with callback can be solved by adjusting the callback delay with isdnctrl cbdelay. One second on the triggering side A (set callback mode to out) and two seconds on the triggered side B (set callback mode to in) has been successful in most cases.

The reason for the problem is a design bug in the link level driver. A calls B to trigger a callback. B rejects the call and calls back to A, establishing a working connection within less than 4 seconds. However, the triggering call from A to B will need 4 seconds to be terminated by the ISDN provider (giving other devices on B's side a chance to take the call). When it is finally terminated, the working connection from B to A is unfortunately also terminated.

22.2 callback_cisco: Somehow i4l can not callback a Cisco?

Torsten Hentschel Torsten.Hentschel@DInet.de wrote on 3 Oct 1996:

A Cisco may dial so heavily that the ipppd has no chance to callback. That's how they are programmed (firm statement of a Cisco developer): If a Cisco receives a packet that should be routed through a "dial on demand" telephone connection, and there is a D-channel available for dialing out, it dials out immediately. If in such a situation (which has be the case with Delta Internet for half a year now) a Cisco with 8 D-channels is on the other side and somebody does a simple "ping RemoteIP" then the Cisco will use (worst case) all 8 D-channels to dial out. Of course it can't dial the same telephone number with two D-channels in parallel (would be immediately busy). Its programming is not so stupid, but it sets up the next D-channel for dialout before it assumes the previous D-channel as failed. Such a Cisco works like a machine gun in respect to dialout. And i4l won't get a free D-channel for dialin if the Cisco doesn't want. The bad thing: a Cisco always expects (even when configured on "callback client" = i4l dials back) that the other side unhooks the line, then both hang up and then comes the callback. Username and password always have to be exchanged before the callback is allowed when using PPP, to be sure that the person requesting callback is allowed to do so. (Cisco seems to obey the rules of the (German) Telekom that no information are to be ex- changed without a B-channel connection. A callback request just by caller id could in doubt be considered as a transmission of information).

I've often tried callback over PPP with two CISCOs. From my experience, trials in the combination CISCO - Linux will not be successful. A CISCO always handshakes a callback request via PPP. To do this, the other side has to first unhook and then do all the handshaking (authentication,...). Then both hang up and the callback is placed. isdnctrl commands of Linux influence only the kernels net devices and have no or hardly any influence on how the ipppd handles callbacks. He does not recognize that he is supposed to expect that the remote side calls back. Accordingly he rejects the offer of the CISCO via PPP, that the CISCO is ready to call back. Then the CISCO assumes that it should not call back (it wants to see an explicit callback request during the PPP handshaking). The CISCO will confirm this when you log onto it and check with these commands: deb ppp chap deb ppp negotiotion deb ppp error term mon its debug messages about the dial in trials of your Linux computer. You have to do this via telnet instead of on the console - otherwise the CISCO won't be able to handle the logging via the serial interface.

22.3 callback_ascend: Callback from an Ascend works only when I set "Active=Yes" in the Ascend menu; but then the Ascend keeps calling me, even when my machine is off.

Ulrich Klein ulik@hprc.tandem.com wrote on 14 Dec 1996:

Somewhere in the Ascend menus you can set "dial broadcast" to "no" or "off". Otherwise the thing will dial with every broadcast. At least that helped me. In case anyone from the network on which the Ascend is attached really wants to establish a connection, then you have to use the strange filters. I believe there's one that will dial out only for callback.

22.4 callback_banzai: How can I callback a Banzai!?

Jan-Olaf Droese jano@layla.RoBIN.de wrote on 31 Jan 1997:

On the Banzai side, a "c" should be added to the outgoing number, so it will be ready for the return call. Just to be safe, you can the dialout attempts on the Banzai to 1, so there won't be any call collisions. On the i4l I've set the following:

isdnctrl callback isdn0 in
isdnctrl cbdelay isdn0 1

22.5 callback_microsoft: Does isdn4linux support Microsoft Callback (CBCP)?

Yes, this is implemented in ipppd. To enable it you have to set the parameter "callback 6" as an ipppd option on the client side for an admin managed callback. This means the server will call back on the number it has been configured for. More interesting is a user managed callback, since the number to be called back can be provided by the user. Set the paramter "callback 123456" if you want to be dialed back on number 123456. To start the callback trigger it from the client via:

isdnctrl cbdelay <device> 5
isdnctrl callback <device> out

- 'callback type[,message]' enables the callback feature
  also UNTESTED!
  ie: 'callback 0'       -> simple callback (info via auth. etc.)
      'callback 3,12346' -> us E.164 (tel) number 123456 for callback
      'callback 6' is different. This value means, that the whole negotiation
  is done with a seperate protocol after the authentification phase. Currently
  it's not possible to set any options in this case. The ipppd accepts
  everything from the remote side.

If you have a Red Hat distribution, setting the following parameters in ifcfg-ippp0 might do the trick for an admin managed callback:

CALLBACK=out
CBDELAY=5
CBCP=on