summaryrefslogtreecommitdiffstats
path: root/Documentation/isdn
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/isdn')
-rw-r--r--Documentation/isdn/INTERFACE759
-rw-r--r--Documentation/isdn/INTERFACE.fax163
-rw-r--r--Documentation/isdn/README599
-rw-r--r--Documentation/isdn/README.FAQ26
-rw-r--r--Documentation/isdn/README.audio138
-rw-r--r--Documentation/isdn/README.concap259
-rw-r--r--Documentation/isdn/README.diversion127
-rw-r--r--Documentation/isdn/README.fax45
-rw-r--r--Documentation/isdn/README.hfc-pci41
-rw-r--r--Documentation/isdn/README.syncppp58
-rw-r--r--Documentation/isdn/README.x25184
-rw-r--r--Documentation/isdn/syncPPP.FAQ224
12 files changed, 0 insertions, 2623 deletions
diff --git a/Documentation/isdn/INTERFACE b/Documentation/isdn/INTERFACE
deleted file mode 100644
index 5df17e5b25c8..000000000000
--- a/Documentation/isdn/INTERFACE
+++ /dev/null
@@ -1,759 +0,0 @@
-$Id: INTERFACE,v 1.15.8.2 2001/03/13 16:17:07 kai Exp $
-
-Description of the Interface between Linklevel and Hardwarelevel
- of isdn4linux:
-
-
- The Communication between Linklevel (LL) and Hardwarelevel (HL)
- is based on the struct isdn_if (defined in isdnif.h).
-
- An HL-driver can register itself at LL by calling the function
- register_isdn() with a pointer to that struct. Prior to that, it has
- to preset some of the fields of isdn_if. The LL sets the rest of
- the fields. All further communication is done via callbacks using
- the function-pointers defined in isdn_if.
-
- Changes/Version numbering:
-
- During development of the ISDN subsystem, several changes have been
- made to the interface. Before it went into kernel, the package
- had a unique version number. The last version, distributed separately
- was 0.7.4. When the subsystem went into kernel, every functional unit
- got a separate version number. These numbers are shown at initialization,
- separated by slashes:
-
- c.c/t.t/n.n/p.p/a.a/v.v
-
- where
-
- c.c is the revision of the common code.
- t.t is the revision of the tty related code.
- n.n is the revision of the network related code.
- p.p is the revision of the ppp related code.
- a.a is the revision of the audio related code.
- v.v is the revision of the V.110 related code.
-
- Changes in this document are marked with '***CHANGEx' where x representing
- the version number. If that number starts with 0, it refers to the old,
- separately distributed package. If it starts with one of the letters
- above, it refers to the revision of the corresponding module.
- ***CHANGEIx refers to the revision number of the isdnif.h
-
-1. Description of the fields of isdn_if:
-
- int channels;
-
- This field has to be set by the HL-driver to the number of channels
- supported prior to calling register_isdn(). Upon return of the call,
- the LL puts an id there, which has to be used by the HL-driver when
- invoking the other callbacks.
-
- int maxbufsize;
-
- ***CHANGE0.6: New since this version.
-
- Also to be preset by the HL-driver. With this value the HL-driver
- tells the LL the maximum size of a data-packet it will accept.
-
- unsigned long features;
-
- To be preset by the HL-driver. Using this field, the HL-driver
- announces the features supported. At the moment this is limited to
- report the supported layer2 and layer3-protocols. For setting this
- field the constants ISDN_FEATURE..., declared in isdnif.h have to be
- used.
-
- ***CHANGE0.7.1: The line type (1TR6, EDSS1) has to be set.
-
- unsigned short hl_hdrlen;
-
- ***CHANGE0.7.4: New field.
-
- To be preset by the HL-driver, if it supports sk_buff's. The driver
- should put here the amount of additional space needed in sk_buff's for
- its internal purposes. Drivers not supporting sk_buff's should
- initialize this field to 0.
-
- void (*rcvcallb_skb)(int, int, struct sk_buff *)
-
- ***CHANGE0.7.4: New field.
-
- This field will be set by LL. The HL-driver delivers received data-
- packets by calling this function. Upon calling, the HL-driver must
- already have its private data pulled off the head of the sk_buff.
-
- Parameter:
- int driver-Id
- int Channel-number locally to the driver. (starting with 0)
- struct sk_buff * Pointer to sk_buff, containing received data.
-
- int (*statcallb)(isdn_ctrl*);
-
- This field will be set by LL. This function has to be called by the
- HL-driver for signaling status-changes or other events to the LL.
-
- Parameter:
- isdn_ctrl*
-
- The struct isdn_ctrl also defined in isdn_if. The exact meanings of its
- fields are described together with the descriptions of the possible
- events. Here is only a short description of the fields:
-
- driver = driver Id.
- command = event-type. (one of the constants ISDN_STAT_...)
- arg = depends on event-type.
- num = depends on event-type.
-
- Returnvalue:
- 0 on success, else -1
-
- int (*command)(isdn_ctrl*);
-
- This field has to be preset by the HL-driver. It points to a function,
- to be called by LL to perform functions like dialing, B-channel
- setup, etc. The exact meaning of the parameters is described with the
- descriptions of the possible commands.
-
- Parameter:
- isdn_ctrl*
- driver = driver-Id
- command = command to perform. (one of the constants ISDN_CMD_...)
- arg = depends on command.
- num = depends on command.
-
- Returnvalue:
- >=0 on success, else error-code (-ENODEV etc.)
-
- int (*writebuf_skb)(int, int, int, struct sk_buff *)
-
- ***CHANGE0.7.4: New field.
- ***CHANGEI.1.21: New field.
-
- This field has to be preset by the HL-driver. The given function will
- be called by the LL for delivering data to be send via B-Channel.
-
-
- Parameter:
- int driver-Id ***CHANGE0.7.4: New parameter.
- int channel-number locally to the HL-driver. (starts with 0)
- int ack ***ChangeI1.21: New parameter
- If this is !0, the driver has to signal the delivery
- by sending an ISDN_STAT_BSENT. If this is 0, the driver
- MUST NOT send an ISDN_STAT_BSENT.
- struct sk_buff * Pointer to sk_buff containing data to be send via
- B-channel.
-
- Returnvalue:
- Length of data accepted on success, else error-code (-EINVAL on
- oversized packets etc.)
-
- int (*writecmd)(u_char*, int, int, int, int);
-
- This field has to be preset by the HL-driver. The given function will be
- called to perform write-requests on /dev/isdnctrl (i.e. sending commands
- to the card) The data-format is hardware-specific. This function is
- intended for debugging only. It is not necessary for normal operation
- and never will be called by the tty-emulation- or network-code. If
- this function is not supported, the driver has to set NULL here.
-
- Parameter:
- u_char* pointer to data.
- int length of data.
- int flag: 0 = call from within kernel-space. (HL-driver must use
- memcpy, may NOT use schedule())
- 1 = call from user-space. (HL-driver must use
- memcpy_fromfs, use of schedule() allowed)
- int driver-Id.
- int channel-number locally to the HL-driver. (starts with 0)
-
-***CHANGEI1.14: The driver-Id and channel-number are new since this revision.
-
- Returnvalue:
- Length of data accepted on success, else error-code (-EINVAL etc.)
-
- int (*readstat)(u_char*, int, int, int, int);
-
- This field has to be preset by the HL-driver. The given function will be
- called to perform read-requests on /dev/isdnctrl (i.e. reading replies
- from the card) The data-format is hardware-specific. This function is
- intended for debugging only. It is not necessary for normal operation
- and never will be called by the tty-emulation- or network-code. If
- this function is not supported, the driver has to set NULL here.
-
- Parameter:
- u_char* pointer to data.
- int length of data.
- int flag: 0 = call from within kernel-space. (HL-driver must use
- memcpy, may NOT use schedule())
- 1 = call from user-space. (HL-driver must use
- memcpy_fromfs, use of schedule() allowed)
- int driver-Id.
- int channel-number locally to the HL-driver. (starts with 0)
-
-***CHANGEI1.14: The driver-Id and channel-number are new since this revision.
-
- Returnvalue:
- Length of data on success, else error-code (-EINVAL etc.)
-
- char id[20];
- ***CHANGE0.7: New since this version.
-
- This string has to be preset by the HL-driver. Its purpose is for
- identification of the driver by the user. Eg.: it is shown in the
- status-info of /dev/isdninfo. Furthermore it is used as Id for binding
- net-interfaces to a specific channel. If a string of length zero is
- given, upon return, isdn4linux will replace it by a generic name. (line0,
- line1 etc.) It is recommended to make this string configurable during
- module-load-time. (copy a global variable to this string.) For doing that,
- modules 1.2.8 or newer are necessary.
-
-2. Description of the commands, a HL-driver has to support:
-
- All commands will be performed by calling the function command() described
- above from within the LL. The field command of the struct-parameter will
- contain the desired command, the field driver is always set to the
- appropriate driver-Id.
-
- Until now, the following commands are defined:
-
-***CHANGEI1.34: The parameter "num" has been replaced by a union "parm" containing
- the old "num" and a new setup_type struct used for ISDN_CMD_DIAL
- and ISDN_STAT_ICALL callback.
-
- ISDN_CMD_IOCTL:
-
- This command is intended for performing ioctl-calls for configuring
- hardware or similar purposes (setting port-addresses, loading firmware
- etc.) For this purpose, in the LL all ioctl-calls with an argument
- >= IIOCDRVCTL (0x100) will be handed transparently to this
- function after subtracting 0x100 and placing the result in arg.
- Example:
- If a userlevel-program calls ioctl(0x101,...) the function gets
- called with the field command set to 1.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_IOCTL
- arg = Original ioctl-cmd - IIOCDRVCTL
- parm.num = first bytes filled with (unsigned long)arg
-
- Returnvalue:
- Depending on driver.
-
-
- ISDN_CMD_DIAL:
-
- This command is used to tell the HL-driver it should dial a given
- number.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_DIAL
- arg = channel-number locally to the driver. (starting with 0)
-
- parm.setup.phone = An ASCII-String containing the number to dial.
- parm.setup.eazmsn = An ASCII-Sting containing the own EAZ or MSN.
- parm.setup.si1 = The Service-Indicator.
- parm.setup.si2 = Additional Service-Indicator.
-
- If the Line has been designed as SPV (a special german
- feature, meaning semi-leased-line) the phone has to
- start with an "S".
- ***CHANGE0.6: In previous versions the EAZ has been given in the
- highbyte of arg.
- ***CHANGE0.7.1: New since this version: ServiceIndicator and AddInfo.
-
- ISDN_CMD_ACCEPTD:
-
- With this command, the HL-driver is told to accept a D-Channel-setup.
- (Response to an incoming call)
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_ACCEPTD
- arg = channel-number locally to the driver. (starting with 0)
- parm = unused.
-
- ISDN_CMD_ACCEPTB:
-
- With this command, the HL-driver is told to perform a B-Channel-setup.
- (after establishing D-Channel-Connection)
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_ACCEPTB
- arg = channel-number locally to the driver. (starting with 0)
- parm = unused.
-
- ISDN_CMD_HANGUP:
-
- With this command, the HL-driver is told to hangup (B-Channel if
- established first, then D-Channel). This command is also used for
- actively rejecting an incoming call.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_HANGUP
- arg = channel-number locally to the driver. (starting with 0)
- parm = unused.
-
- ISDN_CMD_CLREAZ:
-
- With this command, the HL-driver is told not to signal incoming
- calls to the LL.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_CLREAZ
- arg = channel-number locally to the driver. (starting with 0)
- parm = unused.
-
- ISDN_CMD_SETEAZ:
-
- With this command, the HL-driver is told to signal incoming calls for
- the given EAZs/MSNs to the LL.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_SETEAZ
- arg = channel-number locally to the driver. (starting with 0)
- parm.num = ASCII-String, containing the desired EAZ's/MSN's
- (comma-separated). If an empty String is given, the
- HL-driver should respond to ALL incoming calls,
- regardless of the destination-address.
- ***CHANGE0.6: New since this version the "empty-string"-feature.
-
- ISDN_CMD_GETEAZ: (currently unused)
-
- With this command, the HL-driver is told to report the current setting
- given with ISDN_CMD_SETEAZ.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_GETEAZ
- arg = channel-number locally to the driver. (starting with 0)
- parm.num = ASCII-String, containing the current EAZ's/MSN's
-
- ISDN_CMD_SETSIL: (currently unused)
-
- With this command, the HL-driver is told to signal only incoming
- calls with the given Service-Indicators.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_SETSIL
- arg = channel-number locally to the driver. (starting with 0)
- parm.num = ASCII-String, containing the desired Service-Indicators.
-
- ISDN_CMD_GETSIL: (currently unused)
-
- With this command, the HL-driver is told to return the current
- Service-Indicators it will respond to.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_SETSIL
- arg = channel-number locally to the driver. (starting with 0)
- parm.num = ASCII-String, containing the current Service-Indicators.
-
- ISDN_CMD_SETL2:
-
- With this command, the HL-driver is told to select the given Layer-2-
- protocol. This command is issued by the LL prior to ISDN_CMD_DIAL or
- ISDN_CMD_ACCEPTD.
-
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_SETL2
- arg = channel-number locally to the driver. (starting with 0)
- logical or'ed with (protocol-Id << 8)
- protocol-Id is one of the constants ISDN_PROTO_L2...
- parm = unused.
-
- ISDN_CMD_GETL2: (currently unused)
-
- With this command, the HL-driver is told to return the current
- setting of the Layer-2-protocol.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_GETL2
- arg = channel-number locally to the driver. (starting with 0)
- parm = unused.
- Returnvalue:
- current protocol-Id (one of the constants ISDN_L2_PROTO)
-
- ISDN_CMD_SETL3:
-
- With this command, the HL-driver is told to select the given Layer-3-
- protocol. This command is issued by the LL prior to ISDN_CMD_DIAL or
- ISDN_CMD_ACCEPTD.
-
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_SETL3
- arg = channel-number locally to the driver. (starting with 0)
- logical or'ed with (protocol-Id << 8)
- protocol-Id is one of the constants ISDN_PROTO_L3...
- parm.fax = Pointer to T30_s fax struct. (fax usage only)
-
- ISDN_CMD_GETL2: (currently unused)
-
- With this command, the HL-driver is told to return the current
- setting of the Layer-3-protocol.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_GETL3
- arg = channel-number locally to the driver. (starting with 0)
- parm = unused.
- Returnvalue:
- current protocol-Id (one of the constants ISDN_L3_PROTO)
-
- ISDN_CMD_PROCEED:
-
- With this command, the HL-driver is told to proceed with a incoming call.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_PROCEED
- arg = channel-number locally to the driver. (starting with 0)
- setup.eazmsn= empty string or string send as uus1 in DSS1 with
- PROCEED message
-
- ISDN_CMD_ALERT:
-
- With this command, the HL-driver is told to alert a proceeding call.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_ALERT
- arg = channel-number locally to the driver. (starting with 0)
- setup.eazmsn= empty string or string send as uus1 in DSS1 with
- ALERT message
-
- ISDN_CMD_REDIR:
-
- With this command, the HL-driver is told to redirect a call in proceeding
- or alerting state.
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_REDIR
- arg = channel-number locally to the driver. (starting with 0)
- setup.eazmsn= empty string or string send as uus1 in DSS1 protocol
- setup.screen= screening indicator
- setup.phone = redirected to party number
-
- ISDN_CMD_PROT_IO:
-
- With this call, the LL-driver invokes protocol specific features through
- the LL.
- The call is not implicitely bound to a connection.
-
- Parameter:
- driver = driver-Id
- command = ISDN_CMD_PROT_IO
- arg = The lower 8 Bits define the addressed protocol as defined
- in ISDN_PTYPE..., the upper bits are used to differentiate
- the protocol specific CMD.
-
- para = protocol and function specific. See isdnif.h for detail.
-
-
- ISDN_CMD_FAXCMD:
-
- With this command the HL-driver receives a fax sub-command.
- For details refer to INTERFACE.fax
-
- Parameter:
- driver = driver-Id.
- command = ISDN_CMD_FAXCMD
- arg = channel-number locally to the driver. (starting with 0)
- parm = unused.
-
-
-3. Description of the events to be signaled by the HL-driver to the LL.
-
- All status-changes are signaled via calling the previously described
- function statcallb(). The field command of the struct isdn_cmd has
- to be set by the HL-driver with the appropriate Status-Id (event-number).
- The field arg has to be set to the channel-number (locally to the driver,
- starting with 0) to which this event applies. (Exception: STAVAIL-event)
-
- Until now, the following Status-Ids are defined:
-
- ISDN_STAT_AVAIL:
-
- With this call, the HL-driver signals the availability of new data
- for readstat(). Used only for debugging-purposes, see description
- of readstat().
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_STAVAIL
- arg = length of available data.
- parm = unused.
-
- ISDN_STAT_ICALL:
- ISDN_STAT_ICALLW:
-
- With this call, the HL-driver signals an incoming call to the LL.
- If ICALLW is signalled the incoming call is a waiting call without
- a available B-chan.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_ICALL
- arg = channel-number, locally to the driver. (starting with 0)
- para.setup.phone = Callernumber.
- para.setup.eazmsn = CalledNumber.
- para.setup.si1 = Service Indicator.
- para.setup.si2 = Additional Service Indicator.
- para.setup.plan = octet 3 from Calling party number Information Element.
- para.setup.screen = octet 3a from Calling party number Information Element.
-
- Return:
- 0 = No device matching this call.
- 1 = At least one device matching this call (RING on ttyI).
- HL-driver may send ALERTING on the D-channel in this case.
- 2 = Call will be rejected.
- 3 = Incoming called party number is currently incomplete.
- Additional digits are required.
- Used for signalling with PtP connections.
- 4 = Call will be held in a proceeding state
- (HL driver sends PROCEEDING)
- Used when a user space prog needs time to interpret a call
- para.setup.eazmsn may be filled with an uus1 message of
- 30 octets maximum. Empty string if no uus.
- 5 = Call will be actively deflected to another party
- Only available in DSS1/EURO protocol
- para.setup.phone must be set to destination party number
- para.setup.eazmsn may be filled with an uus1 message of
- 30 octets maximum. Empty string if no uus.
- -1 = An error happened. (Invalid parameters for example.)
- The keypad support now is included in the dial command.
-
-
- ISDN_STAT_RUN:
-
- With this call, the HL-driver signals availability of the ISDN-card.
- (after initializing, loading firmware)
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_RUN
- arg = unused.
- parm = unused.
-
- ISDN_STAT_STOP:
-
- With this call, the HL-driver signals unavailability of the ISDN-card.
- (before unloading, while resetting/reconfiguring the card)
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_STOP
- arg = unused.
- parm = unused.
-
- ISDN_STAT_DCONN:
-
- With this call, the HL-driver signals the successful establishment of
- a D-Channel-connection. (Response to ISDN_CMD_ACCEPTD or ISDN_CMD_DIAL)
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_DCONN
- arg = channel-number, locally to the driver. (starting with 0)
- parm = unused.
-
- ISDN_STAT_BCONN:
-
- With this call, the HL-driver signals the successful establishment of
- a B-Channel-connection. (Response to ISDN_CMD_ACCEPTB or because the
- remote-station has initiated establishment)
-
- The HL driver should call this when the logical l2/l3 protocol
- connection on top of the physical B-channel is established.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_BCONN
- arg = channel-number, locally to the driver. (starting with 0)
- parm.num = ASCII-String, containing type of connection (for analog
- modem only). This will be appended to the CONNECT message
- e.g. 14400/V.32bis
-
- ISDN_STAT_DHUP:
-
- With this call, the HL-driver signals the shutdown of a
- D-Channel-connection. This could be a response to a prior ISDN_CMD_HANGUP,
- or caused by a remote-hangup or if the remote-station has actively
- rejected a call.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_DHUP
- arg = channel-number, locally to the driver. (starting with 0)
- parm = unused.
-
- ISDN_STAT_BHUP:
-
- With this call, the HL-driver signals the shutdown of a
- B-Channel-connection. This could be a response to a prior ISDN_CMD_HANGUP,
- or caused by a remote-hangup.
-
- The HL driver should call this as soon as the logical l2/l3 protocol
- connection on top of the physical B-channel is released.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_BHUP
- arg = channel-number, locally to the driver. (starting with 0)
- parm = unused.
-
- ISDN_STAT_CINF:
-
- With this call, the HL-driver delivers charge-unit information to the
- LL.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_CINF
- arg = channel-number, locally to the driver. (starting with 0)
- parm.num = ASCII string containing charge-units (digits only).
-
- ISDN_STAT_LOAD: (currently unused)
-
- ISDN_STAT_UNLOAD:
-
- With this call, the HL-driver signals that it will be unloaded now. This
- tells the LL to release all corresponding data-structures.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_UNLOAD
- arg = unused.
- parm = unused.
-
- ISDN_STAT_BSENT:
-
- With this call the HL-driver signals the delivery of a data-packet.
- This callback is used by the network-interfaces only, tty-Emulation
- does not need this call.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_BSENT
- arg = channel-number, locally to the driver. (starting with 0)
- parm.length = ***CHANGEI.1.21: New field.
- the driver has to set this to the original length
- of the skb at the time of receiving it from the linklevel.
-
- ISDN_STAT_NODCH:
-
- With this call, the driver has to respond to a prior ISDN_CMD_DIAL, if
- no D-Channel is available.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_NODCH
- arg = channel-number, locally to the driver. (starting with 0)
- parm = unused.
-
- ISDN_STAT_ADDCH:
-
- This call is for HL-drivers, which are unable to check card-type
- or numbers of supported channels before they have loaded any firmware
- using ioctl. Those HL-driver simply set the channel-parameter to a
- minimum channel-number when registering, and later if they know
- the real amount, perform this call, allocating additional channels.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_ADDCH
- arg = number of channels to be added.
- parm = unused.
-
- ISDN_STAT_CAUSE:
-
- With this call, the HL-driver delivers CAUSE-messages to the LL.
- Currently the LL does not use this messages. Their contents is simply
- logged via kernel-messages. Therefore, currently the format of the
- messages is completely free. However they should be printable.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_NODCH
- arg = channel-number, locally to the driver. (starting with 0)
- parm.num = ASCII string containing CAUSE-message.
-
- ISDN_STAT_DISPLAY:
-
- With this call, the HL-driver delivers DISPLAY-messages to the LL.
- Currently the LL does not use this messages.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_DISPLAY
- arg = channel-number, locally to the driver. (starting with 0)
- para.display= string containing DISPLAY-message.
-
- ISDN_STAT_PROT:
-
- With this call, the HL-driver delivers protocol specific infos to the LL.
- The call is not implicitely bound to a connection.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_PROT
- arg = The lower 8 Bits define the addressed protocol as defined
- in ISDN_PTYPE..., the upper bits are used to differentiate
- the protocol specific STAT.
-
- para = protocol and function specific. See isdnif.h for detail.
-
- ISDN_STAT_DISCH:
-
- With this call, the HL-driver signals the LL to disable or enable the
- use of supplied channel and driver.
- The call may be used to reduce the available number of B-channels after
- loading the driver. The LL has to ignore a disabled channel when searching
- for free channels. The HL driver itself never delivers STAT callbacks for
- disabled channels.
- The LL returns a nonzero code if the operation was not successful or the
- selected channel is actually regarded as busy.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_DISCH
- arg = channel-number, locally to the driver. (starting with 0)
- parm.num[0] = 0 if channel shall be disabled, else enabled.
-
- ISDN_STAT_L1ERR:
-
- ***CHANGEI1.21 new status message.
- A signal can be sent to the linklevel if an Layer1-error results in
- packet-loss on receive or send. The field errcode of the cmd.parm
- union describes the error more precisely.
-
- Parameter:
- driver = driver-Id
- command = ISDN_STAT_L1ERR
- arg = channel-number, locally to the driver. (starting with 0)
- parm.errcode= ISDN_STAT_L1ERR_SEND: Packet lost while sending.
- ISDN_STAT_L1ERR_RECV: Packet lost while receiving.
- ISDN_STAT_FAXIND:
-
- With this call the HL-driver signals a fax sub-command to the LL.
- For details refer to INTERFACE.fax
-
- Parameter:
- driver = driver-Id.
- command = ISDN_STAT_FAXIND
- arg = channel-number, locally to the driver. (starting with 0)
- parm = unused.
-
diff --git a/Documentation/isdn/INTERFACE.fax b/Documentation/isdn/INTERFACE.fax
deleted file mode 100644
index 9c8c6d914ec7..000000000000
--- a/Documentation/isdn/INTERFACE.fax
+++ /dev/null
@@ -1,163 +0,0 @@
-$Id: INTERFACE.fax,v 1.2 2000/08/06 09:22:50 armin Exp $
-
-
-Description of the fax-subinterface between linklevel and hardwarelevel of
- isdn4linux.
-
- The communication between linklevel (LL) and hardwarelevel (HL) for fax
- is based on the struct T30_s (defined in isdnif.h).
- This struct is allocated in the LL.
- In order to use fax, the LL provides the pointer to this struct with the
- command ISDN_CMD_SETL3 (parm.fax). This pointer expires in case of hangup
- and when a new channel to a new connection is assigned.
-
-
-Data handling:
- In send-mode the HL-driver has to handle the <DLE> codes and the bit-order
- conversion by itself.
- In receive-mode the LL-driver takes care of the bit-order conversion
- (specified by +FBOR)
-
-Structure T30_s description:
-
- This structure stores the values (set by AT-commands), the remote-
- capability-values and the command-codes between LL and HL.
-
- If the HL-driver receives ISDN_CMD_FAXCMD, all needed information
- is in this struct set by the LL.
- To signal information to the LL, the HL-driver has to set the
- parameters and use ISDN_STAT_FAXIND.
- (Please refer to INTERFACE)
-
-Structure T30_s:
-
- All members are 8-bit unsigned (__u8)
-
- - resolution
- - rate
- - width
- - length
- - compression
- - ecm
- - binary
- - scantime
- - id[]
- Local faxmachine's parameters, set by +FDIS, +FDCS, +FLID, ...
-
- - r_resolution
- - r_rate
- - r_width
- - r_length
- - r_compression
- - r_ecm
- - r_binary
- - r_scantime
- - r_id[]
- Remote faxmachine's parameters. To be set by HL-driver.
-
- - phase
- Defines the actual state of fax connection. Set by HL or LL
- depending on progress and type of connection.
- If the phase changes because of an AT command, the LL driver
- changes this value. Otherwise the HL-driver takes care of it, but
- only necessary on call establishment (from IDLE to PHASE_A).
- (one of the constants ISDN_FAX_PHASE_[IDLE,A,B,C,D,E])
-
- - direction
- Defines outgoing/send or incoming/receive connection.
- (ISDN_TTY_FAX_CONN_[IN,OUT])
-
- - code
- Commands from LL to HL; possible constants :
- ISDN_TTY_FAX_DR signals +FDR command to HL
-
- ISDN_TTY_FAX_DT signals +FDT command to HL
-
- ISDN_TTY_FAX_ET signals +FET command to HL
-
-
- Other than that the "code" is set with the hangup-code value at
- the end of connection for the +FHNG message.
-
- - r_code
- Commands from HL to LL; possible constants :
- ISDN_TTY_FAX_CFR output of +FCFR message.
-
- ISDN_TTY_FAX_RID output of remote ID set in r_id[]
- (+FCSI/+FTSI on send/receive)
-
- ISDN_TTY_FAX_DCS output of +FDCS and CONNECT message,
- switching to phase C.
-
- ISDN_TTY_FAX_ET signals end of data,
- switching to phase D.
-
- ISDN_TTY_FAX_FCON signals the established, outgoing connection,
- switching to phase B.
-
- ISDN_TTY_FAX_FCON_I signals the established, incoming connection,
- switching to phase B.
-
- ISDN_TTY_FAX_DIS output of +FDIS message and values.
-
- ISDN_TTY_FAX_SENT signals that all data has been sent
- and <DLE><ETX> is acknowledged,
- OK message will be sent.
-
- ISDN_TTY_FAX_PTS signals a msg-confirmation (page sent successful),
- depending on fet value:
- 0: output OK message (more pages follow)
- 1: switching to phase B (next document)
-
- ISDN_TTY_FAX_TRAIN_OK output of +FDCS and OK message (for receive mode).
-
- ISDN_TTY_FAX_EOP signals end of data in receive mode,
- switching to phase D.
-
- ISDN_TTY_FAX_HNG output of the +FHNG and value set by code and
- OK message, switching to phase E.
-
-
- - badlin
- Value of +FBADLIN
-
- - badmul
- Value of +FBADMUL
-
- - bor
- Value of +FBOR
-
- - fet
- Value of +FET command in send-mode.
- Set by HL in receive-mode for +FET message.
-
- - pollid[]
- ID-string, set by +FCIG
-
- - cq
- Value of +FCQ
-
- - cr
- Value of +FCR
-
- - ctcrty
- Value of +FCTCRTY
-
- - minsp
- Value of +FMINSP
-
- - phcto
- Value of +FPHCTO
-
- - rel
- Value of +FREL
-
- - nbc
- Value of +FNBC (0,1)
- (+FNBC is not a known class 2 fax command, I added this to change the
- automatic "best capabilities" connection in the eicon HL-driver)
-
-
-Armin
-mac@melware.de
-
diff --git a/Documentation/isdn/README b/Documentation/isdn/README
deleted file mode 100644
index 74bd2bdb455b..000000000000
--- a/Documentation/isdn/README
+++ /dev/null
@@ -1,599 +0,0 @@
-README for the ISDN-subsystem
-
-1. Preface
-
- 1.1 Introduction
-
- This README describes how to set up and how to use the different parts
- of the ISDN-subsystem.
-
- For using the ISDN-subsystem, some additional userlevel programs are
- necessary. Those programs and some contributed utilities are available
- at
-
- ftp.isdn4linux.de
-
- /pub/isdn4linux/isdn4k-utils-<VersionNumber>.tar.gz
-
-
- We also have set up a mailing-list:
-
- The isdn4linux-project originates in Germany, and therefore by historical
- reasons, the mailing-list's primary language is german. However mails
- written in english have been welcome all the time.
-
- to subscribe: write a email to majordomo@listserv.isdn4linux.de,
- Subject irrelevant, in the message body:
- subscribe isdn4linux <your_email_address>
-
- To write to the mailing-list, write to isdn4linux@listserv.isdn4linux.de
-
- This mailinglist is bidirectionally gated to the newsgroup
-
- de.alt.comm.isdn4linux
-
- There is also a well maintained FAQ in English available at
- https://www.mhessler.de/i4lfaq/
- It can be viewed online, or downloaded in sgml/text/html format.
- The FAQ can also be viewed online at
- https://www.isdn4linux.de/faq/i4lfaq.html
- or downloaded from
- ftp://ftp.isdn4linux.de/pub/isdn4linux/FAQ/
-
- 1.1 Technical details
-
- In the following Text, the terms MSN and EAZ are used.
-
- MSN is the abbreviation for (M)ultiple(S)ubscriber(N)umber, and applies
- to Euro(EDSS1)-type lines. Usually it is simply the phone number.
-
- EAZ is the abbreviation of (E)ndgeraete(A)uswahl(Z)iffer and
- applies to German 1TR6-type lines. This is a one-digit string,
- simply appended to the base phone number
-
- The internal handling is nearly identical, so replace the appropriate
- term to that one, which applies to your local ISDN-environment.
-
- When the link-level-module isdn.o is loaded, it supports up to 16
- low-level-modules with up to 64 channels. (The number 64 is arbitrarily
- chosen and can be configured at compile-time --ISDN_MAX in isdn.h).
- A low-level-driver can register itself through an interface (which is
- defined in isdnif.h) and gets assigned a slot.
- The following char-devices are made available for each channel:
-
- A raw-control-device with the following functions:
- write: raw D-channel-messages (format: depends on driver).
- read: raw D-channel-messages (format: depends on driver).
- ioctl: depends on driver, i.e. for the ICN-driver, the base-address of
- the ports and the shared memory on the card can be set and read
- also the boot-code and the protocol software can be loaded into
- the card.
-
- O N L Y !!! for debugging (no locking against other devices):
- One raw-data-device with the following functions:
- write: data to B-channel.
- read: data from B-channel.
-
- In addition the following devices are made available:
-
- 128 tty-devices (64 cuix and 64 ttyIx) with integrated modem-emulator:
- The functionality is almost the same as that of a serial device
- (the line-discs are handled by the kernel), which lets you run
- SLIP, CSLIP and asynchronous PPP through the devices. We have tested
- Seyon, minicom, CSLIP (uri-dip) PPP, mgetty, XCept and Hylafax.
-
- The modem-emulation supports the following:
- 1.3.1 Commands:
-
- ATA Answer incoming call.
- ATD<No.> Dial, the number may contain:
- [0-9] and [,#.*WPT-S]
- the latter are ignored until 'S'.
- The 'S' must precede the number, if
- the line is a SPV (German 1TR6).
- ATE0 Echo off.
- ATE1 Echo on (default).
- ATH Hang-up.
- ATH1 Off hook (ignored).
- ATH0 Hang-up.
- ATI Return "ISDN for Linux...".
- ATI0 "
- ATI1 "
- ATI2 Report of last connection.
- ATO On line (data mode).
- ATQ0 Enable result codes (default).
- ATQ1 Disable result codes (default).
- ATSx=y Set register x to y.
- ATSx? Show contents of register x.
- ATV0 Numeric responses.
- ATV1 English responses (default).
- ATZ Load registers and EAZ/MSN from Profile.
- AT&Bx Set Send-Packet-size to x (max. 4000)
- The real packet-size may be limited by the
- low-level-driver used. e.g. the HiSax-Module-
- limit is 2000. You will get NO Error-Message,
- if you set it to higher values, because at the
- time of giving this command the corresponding
- driver may not be selected (see "Automatic
- Assignment") however the size of outgoing packets
- will be limited correctly.
- AT&D0 Ignore DTR
- AT&D2 DTR-low-edge: Hang up and return to
- command mode (default).
- AT&D3 Same as AT&D2 but also resets all registers.
- AT&Ex Set the EAZ/MSN for this channel to x.
- AT&F Reset all registers and profile to "factory-defaults"
- AT&Lx Set list of phone numbers to listen on. x is a
- list of wildcard patterns separated by semicolon.
- If this is set, it has precedence over the MSN set
- by AT&E.
- AT&Rx Select V.110 bitrate adaption.
- This command enables V.110 protocol with 9600 baud
- (x=9600), 19200 baud (x=19200) or 38400 baud
- (x=38400). A value of x=0 disables V.110 switching
- back to default X.75. This command sets the following
- Registers:
- Reg 14 (Layer-2 protocol):
- x = 0: 0
- x = 9600: 7
- x = 19200: 8
- x = 38400: 9
- Reg 18.2 = 1
- Reg 19 (Additional Service Indicator):
- x = 0: 0
- x = 9600: 197
- x = 19200: 199
- x = 38400: 198
- Note on value in Reg 19:
- There is _NO_ common convention for 38400 baud.
- The value 198 is chosen arbitrarily. Users
- _MUST_ negotiate this value before establishing
- a connection.
- AT&Sx Set window-size (x = 1..8) (not yet implemented)
- AT&V Show all settings.
- AT&W0 Write registers and EAZ/MSN to profile. See also
- iprofd (5.c in this README).
- AT&X0 BTX-mode and T.70-mode off (default)
- AT&X1 BTX-mode on. (S13.1=1, S13.5=0 S14=0, S16=7, S18=7, S19=0)
- AT&X2 T.70-mode on. (S13.1=1, S13.5=1, S14=0, S16=7, S18=7, S19=0)
- AT+Rx Resume a suspended call with CallID x (x = 1,2,3...)
- AT+Sx Suspend a call with CallID x (x = 1,2,3...)
-
- For voice-mode commands refer to README.audio
-
- 1.3.2 Escape sequence:
- During a connection, the emulation reacts just like
- a normal modem to the escape sequence <DELAY>+++<DELAY>.
- (The escape character - default '+' - can be set in the
- register 2).
- The DELAY must at least be 1.5 seconds long and delay
- between the escape characters must not exceed 0.5 seconds.
-
- 1.3.3 Registers:
-
- Nr. Default Description
- 0 0 Answer on ring number.
- (no auto-answer if S0=0).
- 1 0 Count of rings.
- 2 43 Escape character.
- (a value >= 128 disables the escape sequence).
- 3 13 Carriage return character (ASCII).
- 4 10 Line feed character (ASCII).
- 5 8 Backspace character (ASCII).
- 6 3 Delay in seconds before dialing.
- 7 60 Wait for carrier.
- 8 2 Pause time for comma (ignored)
- 9 6 Carrier detect time (ignored)
- 10 7 Carrier loss to disconnect time (ignored).
- 11 70 Touch tone timing (ignored).
- 12 69 Bit coded register:
- Bit 0: 0 = Suppress response messages.
- 1 = Show response messages.
- Bit 1: 0 = English response messages.
- 1 = Numeric response messages.
- Bit 2: 0 = Echo off.
- 1 = Echo on.
- Bit 3 0 = DCD always on.
- 1 = DCD follows carrier.
- Bit 4 0 = CTS follows RTS
- 1 = Ignore RTS, CTS always on.
- Bit 5 0 = return to command mode on DTR low.
- 1 = Same as 0 but also resets all
- registers.
- See also register 13, bit 2
- Bit 6 0 = DSR always on.
- 1 = DSR only on if channel is available.
- Bit 7 0 = Cisco-PPP-flag-hack off (default).
- 1 = Cisco-PPP-flag-hack on.
- 13 0 Bit coded register:
- Bit 0: 0 = Use delayed tty-send-algorithm
- 1 = Direct tty-send.
- Bit 1: 0 = T.70 protocol (Only for BTX!) off
- 1 = T.70 protocol (Only for BTX!) on
- Bit 2: 0 = Don't hangup on DTR low.
- 1 = Hangup on DTR low.
- Bit 3: 0 = Standard response messages
- 1 = Extended response messages
- Bit 4: 0 = CALLER NUMBER before every RING.
- 1 = CALLER NUMBER after first RING.
- Bit 5: 0 = T.70 extended protocol off
- 1 = T.70 extended protocol on
- Bit 6: 0 = Special RUNG Message off
- 1 = Special RUNG Message on
- "RUNG" is delivered on a ttyI, if
- an incoming call happened (RING) and
- the remote party hung up before any
- local ATA was given.
- Bit 7: 0 = Don't show display messages from net
- 1 = Show display messages from net
- (S12 Bit 1 must be 0 too)
- 14 0 Layer-2 protocol:
- 0 = X75/LAPB with I-frames
- 1 = X75/LAPB with UI-frames
- 2 = X75/LAPB with BUI-frames
- 3 = HDLC
- 4 = Transparent (audio)
- 7 = V.110, 9600 baud
- 8 = V.110, 19200 baud
- 9 = V.110, 38400 baud
- 10 = Analog Modem (only if hardware supports this)
- 11 = Fax G3 (only if hardware supports this)
- 15 0 Layer-3 protocol:
- 0 = transparent
- 1 = transparent with audio features (e.g. DSP)
- 2 = Fax G3 Class 2 commands (S14 has to be set to 11)
- 3 = Fax G3 Class 1 commands (S14 has to be set to 11)
- 16 250 Send-Packet-size/16
- 17 8 Window-size (not yet implemented)
- 18 4 Bit coded register, Service-Octet-1 to accept,
- or to be used on dialout:
- Bit 0: Service 1 (audio) when set.
- Bit 1: Service 5 (BTX) when set.
- Bit 2: Service 7 (data) when set.
- Note: It is possible to set more than one
- bit. In this case, on incoming calls
- the selected services are accepted,
- and if the service is "audio", the
- Layer-2-protocol is automatically
- changed to 4 regardless of the setting
- of register 14. On outgoing calls,
- the most significant 1-bit is chosen to
- select the outgoing service octet.
- 19 0 Service-Octet-2
- 20 0 Bit coded register (readonly)
- Service-Octet-1 of last call.
- Bit mapping is the same as register 18
- 21 0 Bit coded register (readonly)
- Set on incoming call (during RING) to
- octet 3 of calling party number IE (Numbering plan)
- See section 4.5.10 of ITU Q.931
- 22 0 Bit coded register (readonly)
- Set on incoming call (during RING) to
- octet 3a of calling party number IE (Screening info)
- See section 4.5.10 of ITU Q.931
- 23 0 Bit coded register:
- Bit 0: 0 = Add CPN to RING message off
- 1 = Add CPN to RING message on
- Bit 1: 0 = Add CPN to FCON message off
- 1 = Add CPN to FCON message on
- Bit 2: 0 = Add CDN to RING/FCON message off
- 1 = Add CDN to RING/FCON message on
-
- Last but not least a (at the moment fairly primitive) device to request
- the line-status (/dev/isdninfo) is made available.
-
- Automatic assignment of devices to lines:
-
- All inactive physical lines are listening to all EAZs for incoming
- calls and are NOT assigned to a specific tty or network interface.
- When an incoming call is detected, the driver looks first for a network
- interface and then for an opened tty which:
-
- 1. is configured for the same EAZ.
- 2. has the same protocol settings for the B-channel.
- 3. (only for network interfaces if the security flag is set)
- contains the caller number in its access list.
- 4. Either the channel is not bound exclusively to another Net-interface, or
- it is bound AND the other checks apply to exactly this interface.
- (For usage of the bind-features, refer to the isdnctrl-man-page)
-
- Only when a matching interface or tty is found is the call accepted
- and the "connection" between the low-level-layer and the link-level-layer
- is established and kept until the end of the connection.
- In all other cases no connection is established. Isdn4linux can be
- configured to either do NOTHING in this case (which is useful, if
- other, external devices with the same EAZ/MSN are connected to the bus)
- or to reject the call actively. (isdnctrl busreject ...)
-
- For an outgoing call, the inactive physical lines are searched.
- The call is placed on the first physical line, which supports the
- requested protocols for the B-channel. If a net-interface, however
- is pre-bound to a channel, this channel is used directly.
-
- This makes it possible to configure several network interfaces and ttys
- for one EAZ, if the network interfaces are set to secure operation.
- If an incoming call matches one network interface, it gets connected to it.
- If another incoming call for the same EAZ arrives, which does not match
- a network interface, the first tty gets a "RING" and so on.
-
-2 System prerequisites:
-
- ATTENTION!
-
- Always use the latest module utilities. The current version is
- named in Documentation/Changes. Some old versions of insmod
- are not capable of setting the driver-Ids correctly.
-
-3. Lowlevel-driver configuration.
-
- Configuration depends on how the drivers are built. See the
- README.<yourDriver> for information on driver-specific setup.
-
-4. Device-inodes
-
- The major and minor numbers and their names are described in
- Documentation/admin-guide/devices.rst. The major numbers are:
-
- 43 for the ISDN-tty's.
- 44 for the ISDN-callout-tty's.
- 45 for control/info/debug devices.
-
-5. Application
-
- a) For some card-types, firmware has to be loaded into the cards, before
- proceeding with device-independent setup. See README.<yourDriver>
- for how to do that.
-
- b) If you only intend to use ttys, you are nearly ready now.
-
- c) If you want to have really permanent "Modem"-settings on disk, you
- can start the daemon iprofd. Give it a path to a file at the command-
- line. It will store the profile-settings in this file every time
- an AT&W0 is performed on any ISDN-tty. If the file already exists,
- all profiles are initialized from this file. If you want to unload
- any of the modules, kill iprofd first.
-
- d) For networking, continue: Create an interface:
- isdnctrl addif isdn0
-
- e) Set the EAZ (or MSN for Euro-ISDN):
- isdnctrl eaz isdn0 2
-
- (For 1TR6 a single digit is allowed, for Euro-ISDN the number is your
- real MSN e.g.: Phone-Number)
-
- f) Set the number for outgoing calls on the interface:
- isdnctrl addphone isdn0 out 1234567
- ... (this can be executed more than once, all assigned numbers are
- tried in order)
- and the number(s) for incoming calls:
- isdnctrl addphone isdn0 in 1234567
-
- g) Set the timeout for hang-up:
- isdnctrl huptimeout isdn0 <timeout_in_seconds>
-
- h) additionally you may activate charge-hang-up (= Hang up before
- next charge-info, this only works, if your isdn-provider transmits
- the charge-info during and after the connection):
- isdnctrl chargehup isdn0 on
-
- i) Set the dial mode of the interface:
- isdnctrl dialmode isdn0 auto
- "off" means that you (or the system) cannot make any connection
- (neither incoming or outgoing connections are possible). Use
- this if you want to be sure that no connections will be made.
- "auto" means that the interface is in auto-dial mode, and will
- attempt to make a connection whenever a network data packet needs
- the interface's link. Note that this can cause unexpected dialouts,
- and lead to a high phone bill! Some daemons or other pc's that use
- this interface can cause this.
- Incoming connections are also possible.
- "manual" is a dial mode created to prevent the unexpected dialouts.
- In this mode, the interface will never make any connections on its
- own. You must explicitly initiate a connection with "isdnctrl dial
- isdn0". However, after an idle time of no traffic as configured for
- the huptimeout value with isdnctrl, the connection _will_ be ended.
- If you don't want any automatic hangup, set the huptimeout value to 0.
- "manual" is the default.
-
- j) Setup the interface with ifconfig as usual, and set a route to it.
-
- k) (optional) If you run X11 and have Tcl/Tk-wish version 4.0, you can use
- the script tools/tcltk/isdnmon. You can add actions for line-status
- changes. See the comments at the beginning of the script for how to
- do that. There are other tty-based tools in the tools-subdirectory
- contributed by Michael Knigge (imon), Volker Götz (imontty) and
- Andreas Kool (isdnmon).
-
- l) For initial testing, you can set the verbose-level to 2 (default: 0).
- Then all incoming calls are logged, even if they are not addressed
- to one of the configured net-interfaces:
- isdnctrl verbose 2
-
- Now you are ready! A ping to the set address should now result in an
- automatic dial-out (look at syslog kernel-messages).
- The phone numbers and EAZs can be assigned at any time with isdnctrl.
- You can add as many interfaces as you like with addif following the
- directions above. Of course, there may be some limitations. But we have
- tested as many as 20 interfaces without any problem. However, if you
- don't give an interface name to addif, the kernel will assign a name
- which starts with "eth". The number of "eth"-interfaces is limited by
- the kernel.
-
-5. Additional options for isdnctrl:
-
- "isdnctrl secure <InterfaceName> on"
- Only incoming calls, for which the caller-id is listed in the access
- list of the interface are accepted. You can add caller-id's With the
- command "isdnctrl addphone <InterfaceName> in <caller-id>"
- Euro-ISDN does not transmit the leading '0' of the caller-id for an
- incoming call, therefore you should configure it accordingly.
- If the real number for the dialout e.g. is "09311234567" the number
- to configure here is "9311234567". The pattern-match function
- works similar to the shell mechanism.
-
- ? one arbitrary digit
- * zero or arbitrary many digits
- [123] one of the digits in the list
- [1-5] one digit between '1' and '5'
- a '^' as the first character in a list inverts the list
-
-
- "isdnctrl secure <InterfaceName> off"
- Switch off secure operation (default).
-
- "isdnctrl ihup <InterfaceName> [on|off]"
- Switch the hang-up-timer for incoming calls on or off.
-
- "isdnctrl eaz <InterfaceName>"
- Returns the EAZ of an interface.
-
- "isdnctrl delphone <InterfaceName> in|out <number>"
- Deletes a number from one of the access-lists of the interface.
-
- "isdnctrl delif <InterfaceName>"
- Removes the interface (and possible slaves) from the kernel.
- (You have to unregister it with "ifconfig <InterfaceName> down" before).
-
- "isdnctrl callback <InterfaceName> [on|off]"
- Switches an interface to callback-mode. In this mode, an incoming call
- will be rejected and after this the remote-station will be called. If
- you test this feature by using ping, some routers will re-dial very
- quickly, so that the callback from isdn4linux may not be recognized.
- In this case use ping with the option -i <sec> to increase the interval
- between echo-packets.
-
- "isdnctrl cbdelay <InterfaceName> [seconds]"
- Sets the delay (default 5 sec) between an incoming call and start of
- dialing when callback is enabled.
-
- "isdnctrl cbhup <InterfaceName> [on|off]"
- This enables (default) or disables an active hangup (reject) when getting an
- incoming call for an interface which is configured for callback.
-
- "isdnctrl encap <InterfaceName> <EncapType>"
- Selects the type of packet-encapsulation. The encapsulation can be changed
- only while an interface is down.
-
- At the moment the following values are supported:
-
- rawip (Default) Selects raw-IP-encapsulation. This means, MAC-headers
- are stripped off.
- ip IP with type-field. Same as IP but the type-field of the MAC-header
- is preserved.
- x25iface X.25 interface encapsulation (first byte semantics as defined in
- ../networking/x25-iface.txt). Use this for running the linux
- X.25 network protocol stack (AF_X25 sockets) on top of isdn.
- cisco-h A special-mode for communicating with a Cisco, which is configured
- to do "hdlc"
- ethernet No stripping. Packets are sent with full MAC-header.
- The Ethernet-address of the interface is faked, from its
- IP-address: fc:fc:i1:i2:i3:i4, where i1-4 are the IP-addr.-values.
- syncppp Synchronous PPP
-
- uihdlc HDLC with UI-frame-header (for use with DOS ISPA, option -h1)
-
-
- NOTE: x25iface encapsulation is currently experimental. Please
- read README.x25 for further details
-
-
- Watching packets, using standard-tcpdump will fail for all encapsulations
- except ethernet because tcpdump does not know how to handle packets
- without MAC-header. A patch for tcpdump is included in the utility-package
- mentioned above.
-
- "isdnctrl l2_prot <InterfaceName> <L2-ProtocolName>"
- Selects a layer-2-protocol.
- (With the ICN-driver and the HiSax-driver, "x75i" and "hdlc" is available.
- With other drivers, "x75ui", "x75bui", "x25dte", "x25dce" may be
- possible too. See README.x25 for x25 related l2 protocols.)
-
- isdnctrl l3_prot <InterfaceName> <L3-ProtocolName>
- The same for layer-3. (At the moment only "trans" is allowed)
-
- "isdnctrl list <InterfaceName>"
- Shows all parameters of an interface and the charge-info.
- Try "all" as the interface name.
-
- "isdnctrl hangup <InterfaceName>"
- Forces hangup of an interface.
-
- "isdnctrl bind <InterfaceName> <DriverId>,<ChannelNumber> [exclusive]"
- If you are using more than one ISDN card, it is sometimes necessary to
- dial out using a specific card or even preserve a specific channel for
- dialout of a specific net-interface. This can be done with the above
- command. Replace <DriverId> by whatever you assigned while loading the
- module. The <ChannelNumber> is counted from zero. The upper limit
- depends on the card used. At the moment no card supports more than
- 2 channels, so the upper limit is one.
-
- "isdnctrl unbind <InterfaceName>"
- unbinds a previously bound interface.
-
- "isdnctrl busreject <DriverId> on|off"
- If switched on, isdn4linux replies a REJECT to incoming calls, it
- cannot match to any configured interface.
- If switched off, nothing happens in this case.
- You normally should NOT enable this feature, if the ISDN adapter is not
- the only device connected to the S0-bus. Otherwise it could happen that
- isdn4linux rejects an incoming call, which belongs to another device on
- the bus.
-
- "isdnctrl addslave <InterfaceName> <SlaveName>
- Creates a slave interface for channel-bundling. Slave interfaces are
- not seen by the kernel, but their ISDN-part can be configured with
- isdnctrl as usual. (Phone numbers, EAZ/MSN, timeouts etc.) If more
- than two channels are to be bundled, feel free to create as many as you
- want. InterfaceName must be a real interface, NOT a slave. Slave interfaces
- start dialing, if the master interface resp. the previous slave interface
- has a load of more than 7000 cps. They hangup if the load goes under 7000
- cps, according to their "huptimeout"-parameter.
-
- "isdnctrl sdelay <InterfaceName> secs."
- This sets the minimum time an Interface has to be fully loaded, until
- it sends a dial-request to its slave.
-
- "isdnctrl dial <InterfaceName>"
- Forces an interface to start dialing even if no packets are to be
- transferred.
-
- "isdnctrl mapping <DriverId> MSN0,MSN1,MSN2,...MSN9"
- This installs a mapping table for EAZ<->MSN-mapping for a single line.
- Missing MSN's have to be given as "-" or can be omitted, if at the end
- of the commandline.
- With this command, it's now possible to have an interface listening to
- mixed 1TR6- and Euro-Type lines. In this case, the interface has to be
- configured to a 1TR6-type EAZ (one digit). The mapping is also valid
- for tty-emulation. Seen from the interface/tty-level the mapping
- CAN be used, however it's possible to use single tty's/interfaces with
- real MSN's (more digits) also, in which case the mapping will be ignored.
- Here is an example:
-
- You have a 1TR6-type line with base-nr. 1234567 and a Euro-line with
- MSN's 987654, 987655 and 987656. The DriverId for the Euro-line is "EURO".
-
- isdnctrl mapping EURO -,987654,987655,987656,-,987655
- ...
- isdnctrl eaz isdn0 1 # listen on 12345671(1tr6) and 987654(euro)
- ...
- isdnctrl eaz isdn1 4 # listen on 12345674(1tr6) only.
- ...
- isdnctrl eaz isdn2 987654 # listen on 987654(euro) only.
-
- Same scheme is used with AT&E... at the tty's.
-
-6. If you want to write a new low-level-driver, you are welcome.
- The interface to the link-level-module is described in the file INTERFACE.
- If the interface should be expanded for any reason, don't do it
- on your own, send me a mail containing the proposed changes and
- some reasoning about them.
- If other drivers will not be affected, I will include the changes
- in the next release.
- For developers only, there is a second mailing-list. Write to me
- (fritz@isdn4linux.de), if you want to join that list.
-
-Have fun!
-
- -Fritz
-
diff --git a/Documentation/isdn/README.FAQ b/Documentation/isdn/README.FAQ
deleted file mode 100644
index e5dd1addacdd..000000000000
--- a/Documentation/isdn/README.FAQ
+++ /dev/null
@@ -1,26 +0,0 @@
-
-The FAQ for isdn4linux
-======================
-
-Please note that there is a big FAQ available in the isdn4k-utils.
-You find it in:
- isdn4k-utils/FAQ/i4lfaq.sgml
-
-In case you just want to see the FAQ online, or download the newest version,
-you can have a look at my website:
-https://www.mhessler.de/i4lfaq/ (view + download)
-or:
-https://www.isdn4linux.de/faq/4lfaq.html (view)
-
-As the extension tells, the FAQ is in SGML format, and you can convert it
-into text/html/... format by using the sgml2txt/sgml2html/... tools.
-Alternatively, you can also do a 'configure; make all' in the FAQ directory.
-
-
-Please have a look at the FAQ before posting anything in the Mailinglist,
-or the newsgroup!
-
-
-Matthias Hessler
-hessler@isdn4linux.de
-
diff --git a/Documentation/isdn/README.audio b/Documentation/isdn/README.audio
deleted file mode 100644
index 8ebca19290d9..000000000000
--- a/Documentation/isdn/README.audio
+++ /dev/null
@@ -1,138 +0,0 @@
-$Id: README.audio,v 1.8 1999/07/11 17:17:29 armin Exp $
-
-ISDN subsystem for Linux.
- Description of audio mode.
-
-When enabled during kernel configuration, the tty emulator of the ISDN
-subsystem is capable of a reduced set of commands to support audio.
-This document describes the commands supported and the format of
-audio data.
-
-Commands for enabling/disabling audio mode:
-
- AT+FCLASS=8 Enable audio mode.
- This affects the following registers:
- S18: Bits 0 and 2 are set.
- S16: Set to 48 and any further change to
- larger values is blocked.
- AT+FCLASS=0 Disable audio mode.
- Register 18 is set to 4.
- AT+FCLASS=? Show possible modes.
- AT+FCLASS? Report current mode (0 or 8).
-
-Commands supported in audio mode:
-
-All audio mode commands have one of the following forms:
-
- AT+Vxx? Show current setting.
- AT+Vxx=? Show possible settings.
- AT+Vxx=v Set simple parameter.
- AT+Vxx=v,v ... Set complex parameter.
-
-where xx is a two-character code and v are alphanumerical parameters.
-The following commands are supported:
-
- AT+VNH=x Auto hangup setting. NO EFFECT, supported
- for compatibility only.
- AT+VNH? Always reporting "1"
- AT+VNH=? Always reporting "1"
-
- AT+VIP Reset all audio parameters.
-
- AT+VLS=x Line select. x is one of the following:
- 0 = No device.
- 2 = Phone line.
- AT+VLS=? Always reporting "0,2"
- AT+VLS? Show current line.
-
- AT+VRX Start recording. Emulator responds with
- CONNECT and starts sending audio data to
- the application. See below for data format
-
- AT+VSD=x,y Set silence-detection parameters.
- Possible parameters:
- x = 0 ... 31 sensitivity threshold level.
- (default 0 , deactivated)
- y = 0 ... 255 range of interval in units
- of 0.1 second. (default 70)
- AT+VSD=? Report possible parameters.
- AT+VSD? Show current parameters.
-
- AT+VDD=x,y Set DTMF-detection parameters.
- Only possible if online and during this connection.
- Possible parameters:
- x = 0 ... 15 sensitivity threshold level.
- (default 0 , I4L soft-decode)
- (1-15 soft-decode off, hardware on)
- y = 0 ... 255 tone duration in units of 5ms.
- Not for I4L soft decode (default 8, 40ms)
- AT+VDD=? Report possible parameters.
- AT+VDD? Show current parameters.
-
- AT+VSM=x Select audio data format.
- Possible parameters:
- 2 = ADPCM-2
- 3 = ADPCM-3
- 4 = ADPCM-4
- 5 = aLAW
- 6 = uLAW
- AT+VSM=? Show possible audio formats.
-
- AT+VTX Start audio playback. Emulator responds
- with CONNECT and starts sending audio data
- received from the application via phone line.
-General behavior and description of data formats/protocol.
- when a connection is made:
-
- On incoming calls, if the application responds to a RING
- with ATA, depending on the calling service, the emulator
- responds with either CONNECT (data call) or VCON (voice call).
-
- On outgoing voice calls, the emulator responds with VCON
- upon connection setup.
-
- Audio recording.
-
- When receiving audio data, a kind of bisync protocol is used.
- Upon AT+VRX command, the emulator responds with CONNECT, and
- starts sending audio data to the application. There are several
- escape sequences defined, all using DLE (0x10) as Escape char:
-
- <DLE><ETX> End of audio data. (i.e. caused by a
- hangup of the remote side) Emulator stops
- recording, responding with VCON.
- <DLE><DC4> Abort recording, (send by appl.) Emulator
- stops recording, sends DLE,ETX.
- <DLE><DLE> Escape sequence for DLE in data stream.
- <DLE>0 Touchtone "0" received.
- ...
- <DLE>9 Touchtone "9" received.
- <DLE># Touchtone "#" received.
- <DLE>* Touchtone "*" received.
- <DLE>A Touchtone "A" received.
- <DLE>B Touchtone "B" received.
- <DLE>C Touchtone "C" received.
- <DLE>D Touchtone "D" received.
-
- <DLE>q quiet. Silence detected after non-silence.
- <DLE>s silence. Silence detected from the
- start of recording.
-
- Currently unsupported DLE sequences:
-
- <DLE>c FAX calling tone received.
- <DLE>b busy tone received.
-
- Audio playback.
-
- When sending audio data, upon AT+VTX command, emulator responds with
- CONNECT, and starts transferring data from application to the phone line.
- The same DLE sequences apply to this mode.
-
- Full-Duplex-Audio:
-
- When _both_ commands for recording and playback are given in _one_
- AT-command-line (i.e.: "AT+VTX+VRX"), full-duplex-mode is selected.
- In this mode, the only way to stop recording is sending <DLE><DC4>
- and the only way to stop playback is to send <DLE><ETX>.
-
diff --git a/Documentation/isdn/README.concap b/Documentation/isdn/README.concap
deleted file mode 100644
index a76d74845a4c..000000000000
--- a/Documentation/isdn/README.concap
+++ /dev/null
@@ -1,259 +0,0 @@
-Description of the "concap" encapsulation protocol interface
-============================================================
-
-The "concap" interface is intended to be used by network device
-drivers that need to process an encapsulation protocol.
-It is assumed that the protocol interacts with a linux network device by
-- data transmission
-- connection control (establish, release)
-Thus, the mnemonic: "CONnection CONtrolling eNCAPsulation Protocol".
-
-This is currently only used inside the isdn subsystem. But it might
-also be useful to other kinds of network devices. Thus, if you want
-to suggest changes that improve usability or performance of the
-interface, please let me know. I'm willing to include them in future
-releases (even if I needed to adapt the current isdn code to the
-changed interface).
-
-
-Why is this useful?
-===================
-
-The encapsulation protocol used on top of WAN connections or permanent
-point-to-point links are frequently chosen upon bilateral agreement.
-Thus, a device driver for a certain type of hardware must support
-several different encapsulation protocols at once.
-
-The isdn device driver did already support several different
-encapsulation protocols. The encapsulation protocol is configured by a
-user space utility (isdnctrl). The isdn network interface code then
-uses several case statements which select appropriate actions
-depending on the currently configured encapsulation protocol.
-
-In contrast, LAN network interfaces always used a single encapsulation
-protocol which is unique to the hardware type of the interface. The LAN
-encapsulation is usually done by just sticking a header on the data. Thus,
-traditional linux network device drivers used to process the
-encapsulation protocol directly (usually by just providing a hard_header()
-method in the device structure) using some hardware type specific support
-functions. This is simple, direct and efficient. But it doesn't fit all
-the requirements for complex WAN encapsulations.
-
-
- The configurability of the encapsulation protocol to be used
- makes isdn network interfaces more flexible, but also much more
- complex than traditional lan network interfaces.
-
-
-Many Encapsulation protocols used on top of WAN connections will not just
-stick a header on the data. They also might need to set up or release
-the WAN connection. They also might want to send other data for their
-private purpose over the wire, e.g. ppp does a lot of link level
-negotiation before the first piece of user data can be transmitted.
-Such encapsulation protocols for WAN devices are typically more complex
-than encapsulation protocols for lan devices. Thus, network interface
-code for typical WAN devices also tends to be more complex.
-
-
-In order to support Linux' x25 PLP implementation on top of
-isdn network interfaces I could have introduced yet another branch to
-the various case statements inside drivers/isdn/isdn_net.c.
-This eventually made isdn_net.c even more complex. In addition, it made
-isdn_net.c harder to maintain. Thus, by identifying an abstract
-interface between the network interface code and the encapsulation
-protocol, complexity could be reduced and maintainability could be
-increased.
-
-
-Likewise, a similar encapsulation protocol will frequently be needed by
-several different interfaces of even different hardware type, e.g. the
-synchronous ppp implementation used by the isdn driver and the
-asynchronous ppp implementation used by the ppp driver have a lot of
-similar code in them. By cleanly separating the encapsulation protocol
-from the hardware specific interface stuff such code could be shared
-better in future.
-
-
-When operating over dial-up-connections (e.g. telephone lines via modem,
-non-permanent virtual circuits of wide area networks, ISDN) many
-encapsulation protocols will need to control the connection. Therefore,
-some basic connection control primitives are supported. The type and
-semantics of the connection (i.e the ISO layer where connection service
-is provided) is outside our scope and might be different depending on
-the encapsulation protocol used, e.g. for a ppp module using our service
-on top of a modem connection a connect_request will result in dialing
-a (somewhere else configured) remote phone number. For an X25-interface
-module (LAPB semantics, as defined in Documentation/networking/x25-iface.txt)
-a connect_request will ask for establishing a reliable lapb
-datalink connection.
-
-
-The encapsulation protocol currently provides the following
-service primitives to the network device.
-
-- create a new encapsulation protocol instance
-- delete encapsulation protocol instance and free all its resources
-- initialize (open) the encapsulation protocol instance for use.
-- deactivate (close) an encapsulation protocol instance.
-- process (xmit) data handed down by upper protocol layer
-- receive data from lower (hardware) layer
-- process connect indication from lower (hardware) layer
-- process disconnect indication from lower (hardware) layer
-
-
-The network interface driver accesses those primitives via callbacks
-provided by the encapsulation protocol instance within a
-struct concap_proto_ops.
-
-struct concap_proto_ops{
-
- /* create a new encapsulation protocol instance of same type */
- struct concap_proto * (*proto_new) (void);
-
- /* delete encapsulation protocol instance and free all its resources.
- cprot may no longer be referenced after calling this */
- void (*proto_del)(struct concap_proto *cprot);
-
- /* initialize the protocol's data. To be called at interface startup
- or when the device driver resets the interface. All services of the
- encapsulation protocol may be used after this*/
- int (*restart)(struct concap_proto *cprot,
- struct net_device *ndev,
- struct concap_device_ops *dops);
-
- /* deactivate an encapsulation protocol instance. The encapsulation
- protocol may not call any *dops methods after this. */
- int (*close)(struct concap_proto *cprot);
-
- /* process a frame handed down to us by upper layer */
- int (*encap_and_xmit)(struct concap_proto *cprot, struct sk_buff *skb);
-
- /* to be called for each data entity received from lower layer*/
- int (*data_ind)(struct concap_proto *cprot, struct sk_buff *skb);
-
- /* to be called when a connection was set up/down.
- Protocols that don't process these primitives might fill in
- dummy methods here */
- int (*connect_ind)(struct concap_proto *cprot);
- int (*disconn_ind)(struct concap_proto *cprot);
-};
-
-
-The data structures are defined in the header file include/linux/concap.h.
-
-
-A Network interface using encapsulation protocols must also provide
-some service primitives to the encapsulation protocol:
-
-- request data being submitted by lower layer (device hardware)
-- request a connection being set up by lower layer
-- request a connection being released by lower layer
-
-The encapsulation protocol accesses those primitives via callbacks
-provided by the network interface within a struct concap_device_ops.
-
-struct concap_device_ops{
-
- /* to request data be submitted by device */
- int (*data_req)(struct concap_proto *, struct sk_buff *);
-
- /* Control methods must be set to NULL by devices which do not
- support connection control. */
- /* to request a connection be set up */
- int (*connect_req)(struct concap_proto *);
-
- /* to request a connection be released */
- int (*disconn_req)(struct concap_proto *);
-};
-
-The network interface does not explicitly provide a receive service
-because the encapsulation protocol directly calls netif_rx().
-
-
-
-
-An encapsulation protocol itself is actually the
-struct concap_proto{
- struct net_device *net_dev; /* net device using our service */
- struct concap_device_ops *dops; /* callbacks provided by device */
- struct concap_proto_ops *pops; /* callbacks provided by us */
- int flags;
- void *proto_data; /* protocol specific private data, to
- be accessed via *pops methods only*/
- /*
- :
- whatever
- :
- */
-};
-
-Most of this is filled in when the device requests the protocol to
-be reset (opend). The network interface must provide the net_dev and
-dops pointers. Other concap_proto members should be considered private
-data that are only accessed by the pops callback functions. Likewise,
-a concap proto should access the network device's private data
-only by means of the callbacks referred to by the dops pointer.
-
-
-A possible extended device structure which uses the connection controlling
-encapsulation services could look like this:
-
-struct concap_device{
- struct net_device net_dev;
- struct my_priv /* device->local stuff */
- /* the my_priv struct might contain a
- struct concap_device_ops *dops;
- to provide the device specific callbacks
- */
- struct concap_proto *cprot; /* callbacks provided by protocol */
-};
-
-
-
-Misc Thoughts
-=============
-
-The concept of the concap proto might help to reuse protocol code and
-reduce the complexity of certain network interface implementations.
-The trade off is that it introduces yet another procedure call layer
-when processing the protocol. This has of course some impact on
-performance. However, typically the concap interface will be used by
-devices attached to slow lines (like telephone, isdn, leased synchronous
-lines). For such slow lines, the overhead is probably negligible.
-This might no longer hold for certain high speed WAN links (like
-ATM).
-
-
-If general linux network interfaces explicitly supported concap
-protocols (e.g. by a member struct concap_proto* in struct net_device)
-then the interface of the service function could be changed
-by passing a pointer of type (struct net_device*) instead of
-type (struct concap_proto*). Doing so would make many of the service
-functions compatible to network device support functions.
-
-e.g. instead of the concap protocol's service function
-
- int (*encap_and_xmit)(struct concap_proto *cprot, struct sk_buff *skb);
-
-we could have
-
- int (*encap_and_xmit)(struct net_device *ndev, struct sk_buff *skb);
-
-As this is compatible to the dev->hard_start_xmit() method, the device
-driver could directly register the concap protocol's encap_and_xmit()
-function as its hard_start_xmit() method. This would eliminate one
-procedure call layer.
-
-
-The device's data request function could also be defined as
-
- int (*data_req)(struct net_device *ndev, struct sk_buff *skb);
-
-This might even allow for some protocol stacking. And the network
-interface might even register the same data_req() function directly
-as its hard_start_xmit() method when a zero layer encapsulation
-protocol is configured. Thus, eliminating the performance penalty
-of the concap interface when a trivial concap protocol is used.
-Nevertheless, the device remains able to support encapsulation
-protocol configuration.
-
diff --git a/Documentation/isdn/README.diversion b/Documentation/isdn/README.diversion
deleted file mode 100644
index bddcd5fb86ff..000000000000
--- a/Documentation/isdn/README.diversion
+++ /dev/null
@@ -1,127 +0,0 @@
-The isdn diversion services are a supporting module working together with
-the isdn4linux and the HiSax module for passive cards.
-Active cards, TAs and cards using a own or other driver than the HiSax
-module need to be adapted to the HL<->LL interface described in a separate
-document. The diversion services may be used with all cards supported by
-the HiSax driver.
-The diversion kernel interface and controlling tool divertctrl were written
-by Werner Cornelius (werner@isdn4linux.de or werner@titro.de) under the
-GNU General Public License.
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-
-Table of contents
-=================
-
-1. Features of the i4l diversion services
- (Or what can the i4l diversion services do for me)
-
-2. Required hard- and software
-
-3. Compiling, installing and loading/unloading the module
- Tracing calling and diversion information
-
-4. Tracing calling and diversion information
-
-5. Format of the divert device ASCII output
-
-
-1. Features of the i4l diversion services
- (Or what can the i4l diversion services do for me)
-
- The i4l diversion services offers call forwarding and logging normally
- only supported by isdn phones. Incoming calls may be diverted
- unconditionally (CFU), when not reachable (CFNR) or on busy condition
- (CFB).
- The diversions may be invoked statically in the providers exchange
- as normally done by isdn phones. In this case all incoming calls
- with a special (or all) service identifiers are forwarded if the
- forwarding reason is met. Activated static services may also be
- interrogated (queried).
- The i4l diversion services additionally offers a dynamic version of
- call forwarding which is not preprogrammed inside the providers exchange
- but dynamically activated by i4l.
- In this case all incoming calls are checked by rules that may be
- compared to the mechanism of ipfwadm or ipchains. If a given rule matches
- the checking process is finished and the rule matching will be applied
- to the call.
- The rules include primary and secondary service identifiers, called
- number and subaddress, callers number and subaddress and whether the rule
- matches to all filtered calls or only those when all B-channel resources
- are exhausted.
- Actions that may be invoked by a rule are ignore, proceed, reject,
- direct divert or delayed divert of a call.
- All incoming calls matching a rule except the ignore rule a reported and
- logged as ASCII via the proc filesystem (/proc/net/isdn/divert). If proceed
- is selected the call will be held in a proceeding state (without ringing)
- for a certain amount of time to let an external program or client decide
- how to handle the call.
-
-
-2. Required hard- and software
-
- For using the i4l diversion services the isdn line must be of a EURO/DSS1
- type. Additionally the i4l services only work together with the HiSax
- driver for passive isdn cards. All HiSax supported cards may be used for
- the diversion purposes.
- The static diversion services require the provider having static services
- CFU, CFNR, CFB activated on an MSN-line. The static services may not be
- used on a point-to-point connection. Further the static services are only
- available in some countries (for example germany). Countries requiring the
- keypad protocol for activating static diversions (like the netherlands) are
- not supported but may use the tty devices for this purpose.
- The dynamic diversion services may be used in all countries if the provider
- enables the feature CF (call forwarding). This should work on both MSN- and
- point-to-point lines.
- To add and delete rules the additional divertctrl program is needed. This
- program is part of the isdn4kutils package.
-
-3. Compiling, installing and loading/unloading the module
- Tracing calling and diversion information
-
-
- To compile the i4l code with diversion support you need to say yes to the
- DSS1 diversion services when selecting the i4l options in the kernel
- config (menuconfig or config).
- After having properly activated a make modules and make modules_install all
- required modules will be correctly installed in the needed modules dirs.
- As the diversion services are currently not included in the scripts of most
- standard distributions you will have to add a "insmod dss1_divert" after
- having loaded the global isdn module.
- The module can be loaded without any command line parameters.
- If the module is actually loaded and active may be checked with a
- "cat /proc/modules" or "ls /proc/net/isdn/divert". The divert file is
- dynamically created by the diversion module and removed when the module is
- unloaded.
-
-
-4. Tracing calling and diversion information
-
- You also may put a "cat /proc/net/isdn/divert" in the background with the
- output redirected to a file. Then all actions of the module are logged.
- The divert file in the proc system may be opened more than once, so in
- conjunction with inetd and a small remote client on other machines inside
- your network incoming calls and reactions by the module may be shown on
- every listening machine.
- If a call is reported as proceeding an external program or client may
- specify during a certain amount of time (normally 4 to 10 seconds) what
- to do with that call.
- To unload the module all open files to the device in the proc system must
- be closed. Otherwise the module (and isdn.o) may not be unloaded.
-
-5. Format of the divert device ASCII output
-
- To be done later
-
diff --git a/Documentation/isdn/README.fax b/Documentation/isdn/README.fax
deleted file mode 100644
index 5314958a8a6e..000000000000
--- a/Documentation/isdn/README.fax
+++ /dev/null
@@ -1,45 +0,0 @@
-
-Fax with isdn4linux
-===================
-
-When enabled during kernel configuration, the tty emulator
-of the ISDN subsystem is capable of the Fax Class 2 commands.
-
-This only makes sense under the following conditions :
-
-- You need the commands as dummy, because you are using
- hylafax (with patch) for AVM capi.
-- You want to use the fax capabilities of your isdn-card.
- (supported cards are listed below)
-
-
-NOTE: This implementation does *not* support fax with passive
- ISDN-cards (known as softfax). The low-level driver of
- the ISDN-card and/or the card itself must support this.
-
-
-Supported ISDN-Cards
---------------------
-
-Eicon DIVA Server BRI/PCI
- - full support with both B-channels.
-
-Eicon DIVA Server 4BRI/PCI
- - full support with all B-channels.
-
-Eicon DIVA Server PRI/PCI
- - full support on amount of B-channels
- depending on DSPs on board.
-
-
-
-The command set is known as Class 2 (not Class 2.0) and
-can be activated by AT+FCLASS=2
-
-
-The interface between the link-level-module and the hardware-level driver
-is described in the files INTERFACE.fax and INTERFACE.
-
-Armin
-mac@melware.de
-
diff --git a/Documentation/isdn/README.hfc-pci b/Documentation/isdn/README.hfc-pci
deleted file mode 100644
index e8a4ef0226e8..000000000000
--- a/Documentation/isdn/README.hfc-pci
+++ /dev/null
@@ -1,41 +0,0 @@
-The driver for the HFC-PCI and HFC-PCI-A chips from CCD may be used
-for many OEM cards using this chips.
-Additionally the driver has a special feature which makes it possible
-to read the echo-channel of the isdn bus. So all frames in both directions
-may be logged.
-When the echo logging feature is used the number of available B-channels
-for a HFC-PCI card is reduced to 1. Of course this is only relevant to
-the card, not to the isdn line.
-To activate the echo mode the following ioctls must be entered:
-
-hisaxctrl <driver/cardname> 10 1
-
-This reduces the available channels to 1. There must not be open connections
-through this card when entering the command.
-And then:
-
-hisaxctrl <driver/cardname> 12 1
-
-This enables the echo mode. If Hex logging is activated the isdnctrlx
-devices show a output with a line beginning of HEX: for the providers
-exchange and ECHO: for isdn devices sending to the provider.
-
-If more than one HFC-PCI cards are installed, a specific card may be selected
-at the hisax module load command line. Supply the load command with the desired
-IO-address of the desired card.
-Example:
-There tree cards installed in your machine at IO-base addresses 0xd000, 0xd400
-and 0xdc00
-If you want to use the card at 0xd400 standalone you should supply the insmod
-or depmod with type=35 io=0xd400.
-If you want to use all three cards, but the order needs to be at 0xdc00,0xd400,
-0xd000 you may give the parameters type=35,35,35 io=0xdc00,0xd400,0xd00
-Then the desired card will be the initialised in the desired order.
-If the io parameter is used the io addresses of all used cards should be
-supplied else the parameter is assumed 0 and a auto search for a free card is
-invoked which may not give the wanted result.
-
-Comments and reports to werner@isdn4linux.de or werner@isdn-development.de
-
-
-
diff --git a/Documentation/isdn/README.syncppp b/Documentation/isdn/README.syncppp
deleted file mode 100644
index 27d260095cce..000000000000
--- a/Documentation/isdn/README.syncppp
+++ /dev/null
@@ -1,58 +0,0 @@
-Some additional information for setting up a syncPPP
-connection using network interfaces.
----------------------------------------------------------------
-
-You need one thing beside the isdn4linux package:
-
- a patched pppd .. (I called it ipppd to show the difference)
-
-Compiling isdn4linux with sync PPP:
------------------------------------
-To compile isdn4linux with the sync PPP part, you have
-to answer the appropriate question when doing a "make config"
-Don't forget to load the slhc.o
-module before the isdn.o module, if VJ-compression support
-is not compiled into your kernel. (e.g if you have no PPP or
-CSLIP in the kernel)
-
-Using isdn4linux with sync PPP:
--------------------------------
-Sync PPP is just another encapsulation for isdn4linux. The
-name to enable sync PPP encapsulation is 'syncppp' .. e.g:
-
- /sbin/isdnctrl encap ippp0 syncppp
-
-The name of the interface is here 'ippp0'. You need
-one interface with the name 'ippp0' to saturate the
-ipppd, which checks the ppp version via this interface.
-Currently, all devices must have the name ipppX where
-'X' is a decimal value.
-
-To set up a PPP connection you need the ipppd .. You must start
-the ipppd once after installing the modules. The ipppd
-communicates with the isdn4linux link-level driver using the
-/dev/ippp0 to /dev/ippp15 devices. One ipppd can handle
-all devices at once. If you want to use two PPP connections
-at the same time, you have to connect the ipppd to two
-devices .. and so on.
-I've implemented one additional option for the ipppd:
- 'useifip' will get (if set to not 0.0.0.0) the IP address
- for the negotiation from the attached network-interface.
-(also: ipppd will try to negotiate pointopoint IP as remote IP)
-You must disable BSD-compression, this implementation can't
-handle compressed packets.
-
-Check the etc/rc.isdn.syncppp in the isdn4kernel-util package
-for an example setup script.
-
-To use the MPPP stuff, you must configure a slave device
-with isdn4linux. Now call the ipppd with the '+mp' option.
-To increase the number of links, you must use the
-'addlink' option of the isdnctrl tool. (rc.isdn.syncppp.MPPP is
-an example script)
-
-enjoy it,
- michael
-
-
-
diff --git a/Documentation/isdn/README.x25 b/Documentation/isdn/README.x25
deleted file mode 100644
index e561a77c4e22..000000000000
--- a/Documentation/isdn/README.x25
+++ /dev/null
@@ -1,184 +0,0 @@
-
-X.25 support within isdn4linux
-==============================
-
-This is alpha/beta test code. Use it completely at your own risk.
-As new versions appear, the stuff described here might suddenly change
-or become invalid without notice.
-
-Keep in mind:
-
-You are using several new parts of the 2.2.x kernel series which
-have not been tested in a large scale. Therefore, you might encounter
-more bugs as usual.
-
-- If you connect to an X.25 neighbour not operated by yourself, ASK the
- other side first. Be prepared that bugs in the protocol implementation
- might result in problems.
-
-- This implementation has never wiped out my whole hard disk yet. But as
- this is experimental code, don't blame me if that happened to you.
- Backing up important data will never harm.
-
-- Monitor your isdn connections while using this software. This should
- prevent you from undesired phone bills in case of driver problems.
-
-
-
-
-How to configure the kernel
-===========================
-
-The ITU-T (former CCITT) X.25 network protocol layer has been implemented
-in the Linux source tree since version 2.1.16. The isdn subsystem might be
-useful to run X.25 on top of ISDN. If you want to try it, select
-
- "CCITT X.25 Packet Layer"
-
-from the networking options as well as
-
- "ISDN Support" and "X.25 PLP on Top of ISDN"
-
-from the ISDN subsystem options when you configure your kernel for
-compilation. You currently also need to enable
-"Prompt for development and/or incomplete code/drivers" from the
-"Code maturity level options" menu. For the x25trace utility to work
-you also need to enable "Packet socket".
-
-For local testing it is also recommended to enable the isdnloop driver
-from the isdn subsystem's configuration menu.
-
-For testing, it is recommended that all isdn drivers and the X.25 PLP
-protocol are compiled as loadable modules. Like this, you can recover
-from certain errors by simply unloading and reloading the modules.
-
-
-
-What's it for? How to use it?
-=============================
-
-X.25 on top of isdn might be useful with two different scenarios:
-
-- You might want to access a public X.25 data network from your Linux box.
- You can use i4l if you were physically connected to the X.25 switch
- by an ISDN B-channel (leased line as well as dial up connection should
- work).
-
- This corresponds to ITU-T recommendation X.31 Case A (circuit-mode
- access to PSPDN [packet switched public data network]).
-
- NOTE: X.31 also covers a Case B (access to PSPDN via virtual
- circuit / packet mode service). The latter mode (which in theory
- also allows using the D-channel) is not supported by isdn4linux.
- It should however be possible to establish such packet mode connections
- with certain active isdn cards provided that the firmware supports X.31
- and the driver exports this functionality to the user. Currently,
- the AVM B1 driver is the only driver which does so. (It should be
- possible to access D-channel X.31 with active AVM cards using the
- CAPI interface of the AVM-B1 driver).
-
-- Or you might want to operate certain ISDN teleservices on your linux
- box. A lot of those teleservices run on top of the ISO-8208
- (DTE-DTE mode) network layer protocol. ISO-8208 is essentially the
- same as ITU-T X.25.
-
- Popular candidates of such teleservices are EUROfile transfer or any
- teleservice applying ITU-T recommendation T.90.
-
-To use the X.25 protocol on top of isdn, just create an isdn network
-interface as usual, configure your own and/or peer's ISDN numbers,
-and choose x25iface encapsulation by
-
- isdnctrl encap <iface-name> x25iface.
-
-Once encap is set like this, the device can be used by the X.25 packet layer.
-
-All the stuff needed for X.25 is implemented inside the isdn link
-level (mainly isdn_net.c and some new source files). Thus, it should
-work with every existing HL driver. I was able to successfully open X.25
-connections on top of the isdnloop driver and the hisax driver.
-"x25iface"-encapsulation bypasses demand dialing. Dialing will be
-initiated when the upper (X.25 packet) layer requests the lapb datalink to
-be established. But hangup timeout is still active. Whenever a hangup
-occurs, all existing X.25 connections on that link will be cleared
-It is recommended to use sufficiently large hangup-timeouts for the
-isdn interfaces.
-
-
-In order to set up a conforming protocol stack you also need to
-specify the proper l2_prot parameter:
-
-To operate in ISO-8208 X.25 DTE-DTE mode, use
-
- isdnctrl l2_prot <iface-name> x75i
-
-To access an X.25 network switch via isdn (your linux box is the DTE), use
-
- isdnctrl l2_prot <iface-name> x25dte
-
-To mimic an X.25 network switch (DCE side of the connection), use
-
- isdnctrl l2_prot <iface-name> x25dce
-
-However, x25dte or x25dce is currently not supported by any real HL
-level driver. The main difference between x75i and x25dte/dce is that
-x25d[tc]e uses fixed lap_b addresses. With x75i, the side which
-initiates the isdn connection uses the DTE's lap_b address while the
-called side used the DCE's lap_b address. Thus, l2_prot x75i might
-probably work if you access a public X.25 network as long as the
-corresponding isdn connection is set up by you. At least one test
-was successful to connect via isdn4linux to an X.25 switch using this
-trick. At the switch side, a terminal adapter X.21 was used to connect
-it to the isdn.
-
-
-How to set up a test installation?
-==================================
-
-To test X.25 on top of isdn, you need to get
-
-- a recent version of the "isdnctrl" program that supports setting the new
- X.25 specific parameters.
-
-- the x25-utils-2.X package from
- ftp://ftp.hes.iki.fi/pub/ham/linux/ax25/x25utils-*
- (don't confuse the x25-utils with the ax25-utils)
-
-- an application program that uses linux PF_X25 sockets (some are
- contained in the x25-util package).
-
-Before compiling the user level utilities make sure that the compiler/
-preprocessor will fetch the proper kernel header files of this kernel
-source tree. Either make /usr/include/linux a symbolic link pointing to
-this kernel's include/linux directory or set the appropriate compiler flags.
-
-When all drivers and interfaces are loaded and configured you need to
-ifconfig the network interfaces up and add X.25-routes to them. Use
-the usual ifconfig tool.
-
-ifconfig <iface-name> up
-
-But a special x25route tool (distributed with the x25-util package)
-is needed to set up X.25 routes. I.e.
-
-x25route add 01 <iface-name>
-
-will cause all x.25 connections to the destination X.25-address
-"01" to be routed to your created isdn network interface.
-
-There are currently no real X.25 applications available. However, for
-tests, the x25-utils package contains a modified version of telnet
-and telnetd that uses X.25 sockets instead of tcp/ip sockets. You can
-use those for your first tests. Furthermore, you might check
-ftp://ftp.hamburg.pop.de/pub/LOCAL/linux/i4l-eft/ which contains some
-alpha-test implementation ("eftp4linux") of the EUROfile transfer
-protocol.
-
-The scripts distributed with the eftp4linux test releases might also
-provide useful examples for setting up X.25 on top of isdn.
-
-The x25-utility package also contains an x25trace tool that can be
-used to monitor X.25 packets received by the network interfaces.
-The /proc/net/x25* files also contain useful information.
-
-- Henner
diff --git a/Documentation/isdn/syncPPP.FAQ b/Documentation/isdn/syncPPP.FAQ
deleted file mode 100644
index 3257a4bc0786..000000000000
--- a/Documentation/isdn/syncPPP.FAQ
+++ /dev/null
@@ -1,224 +0,0 @@
-simple isdn4linux PPP FAQ .. to be continued .. not 'debugged'
--------------------------------------------------------------------
-
-Q01: what's pppd, ipppd, syncPPP, asyncPPP ??
-Q02: error message "this system lacks PPP support"
-Q03: strange information using 'ifconfig'
-Q04: MPPP?? What's that and how can I use it ...
-Q05: I tried MPPP but it doesn't work
-Q06: can I use asynchronous PPP encapsulation with network devices
-Q07: A SunISDN machine can't connect to my i4l system
-Q08: I wanna talk to several machines, which need different configs
-Q09: Starting the ipppd, I get only error messages from i4l
-Q10: I wanna use dynamic IP address assignment
-Q11: I can't connect. How can I check where the problem is.
-Q12: How can I reduce login delay?
-
--------------------------------------------------------------------
-
-Q01: pppd, ipppd, syncPPP, asyncPPP .. what is that ?
- what should I use?
-A: The pppd is for asynchronous PPP .. asynchronous means
- here, the framing is character based. (e.g when
- using ttyI* or tty* devices)
-
- The ipppd handles PPP packets coming in HDLC
- frames (bit based protocol) ... The PPP driver
- in isdn4linux pushes all IP packets direct
- to the network layer and all PPP protocol
- frames to the /dev/ippp* device.
- So, the ipppd is a simple external network
- protocol handler.
-
- If you login into a remote machine using the
- /dev/ttyI* devices and then enable PPP on the
- remote terminal server -> use the 'old' pppd
-
- If your remote side immediately starts to send
- frames ... you probably connect to a
- syncPPP machine .. use the network device part
- of isdn4linux with the 'syncppp' encapsulation
- and make sure, that the ipppd is running and
- connected to at least one /dev/ippp*. Check the
- isdn4linux manual on how to configure a network device.
-
---
-
-Q02: when I start the ipppd .. I only get the
- error message "this system lacks PPP support"
-A: check that at least the device 'ippp0' exists.
- (you can check this e.g with the program 'ifconfig')
- The ipppd NEEDS this device under THIS name ..
- If this device doesn't exists, use:
- isdnctrl addif ippp0
- isdnctrl encap ippp0 syncppp
- ... (see isdn4linux doc for more) ...
-A: Maybe you have compiled the ipppd with another
- kernel source tree than the kernel you currently
- run ...
-
---
-
-Q03: when I list the netdevices with ifconfig I see, that
- my ISDN interface has a HWaddr and IRQ=0 and Base
- address = 0
-A: The device is a fake ethernet device .. ignore IRQ and baseaddr
- You need the HWaddr only for ethernet encapsulation.
-
---
-
-Q04: MPPP?? What's that and how can I use it ...
-
-A: 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.
- To enable MPPP negotiation you must call the
- ipppd with the '+mp' option.
- You must also configure a slave device for
- every additional channel. (see the i4l manual
- for more)
- 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>
- e.g:
- isdnctrl addlink ippp0
- This is different from other encapsulations of
- isdn4linux! With syncPPP, there is no automatic
- activation of slave devices.
-
---
-
-Q05: I tried MPPP but it doesn't work .. the ipppd
- writes in the debug log something like:
- .. rcvd [0][proto=0x3d] c0 00 00 00 80 fd 01 01 00 0a ...
- .. sent [0][LCP ProtRej id=0x2 00 3d c0 00 00 00 80 fd 01 ...
-
-A: you forgot to compile MPPP/RFC1717 support into the
- ISDN Subsystem. Recompile with this option enabled.
-
---
-
-Q06: can I use asynchronous PPP encapsulation
- over the network interface of isdn4linux ..
-
-A: No .. that's not possible .. Use the standard
- PPP package over the /dev/ttyI* devices. You
- must not use the ipppd for this.
-
---
-
-Q07: A SunISDN machine tries to connect my i4l system,
- which doesn't work.
- Checking the debug log I just saw garbage like:
-!![ ... fill in the line ... ]!!
-
-A: The Sun tries to talk asynchronous PPP ... i4l
- can't understand this ... try to use the ttyI*
- devices with the standard PPP/pppd package
-
-A: (from Alexanter Strauss: )
-!![ ... fill in mail ]!!
-
---
-
-Q08: I wanna talk to remote machines, which need
- a different configuration. The only way
- I found to do this is to kill the ipppd and
- start a new one with another config to connect
- to the second machine.
-
-A: you must bind a network interface explicitly to
- an ippp device, where you can connect a (for this
- interface) individually configured ipppd.
-
---
-
-Q09: When I start the ipppd I only get error messages
- from the i4l driver ..
-
-A: When starting, the ipppd calls functions which may
- trigger a network packet. (e.g gethostbyname()).
- Without the ipppd (at this moment, it is not
- fully started) we can't handle this network request.
- Try to configure hostnames necessary for the ipppd
- in your local /etc/hosts file or in a way, that
- your system can resolve it without using an
- isdn/ippp network-interface.
-
---
-
-Q10: I wanna use dynamic IP address assignment ... How
- must I configure the network device.
-
-A: At least you must have a route which forwards
- a packet to the ippp network-interface to trigger
- the dial-on-demand.
- A default route to the ippp-interface will work.
- Now you must choose a dummy IP address for your
- interface.
- If for some reason you can't set the default
- route to the ippp interface, you may take any
- address of the subnet from which you expect your
- dynamic IP number and set a 'network route' for
- this subnet to the ippp interface.
- To allow overriding of the dummy address you
- must call the ipppd with the 'ipcp-accept-local' option.
-
-A: You must know, how the ipppd gets the addresses it wanna
- configure. If you don't give any option, the ipppd
- tries to negotiate the local host address!
- With the option 'noipdefault' it requests an address
- from the remote machine. With 'useifip' it gets the
- addresses from the net interface. Or you set the address
- on the option line with the <a.b.c.d:e.f.g.h> option.
- Note: the IP address of the remote machine must be configured
- locally or the remote machine must send it in an IPCP request.
- If your side doesn't know the IP address after negotiation, it
- closes the connection!
- You must allow overriding of address with the 'ipcp-accept-*'
- options, if you have set your own or the remote address
- explicitly.
-
-A: Maybe you try these options .. e.g:
-
- /sbin/ipppd :$REMOTE noipdefault /dev/ippp0
-
- where REMOTE must be the address of the remote machine (the
- machine, which gives you your address)
-
---
-
-Q11: I can't connect. How can I check where the problem is.
-
-A: A good help log is the debug output from the ipppd...
- Check whether you can find there:
- - only a few LCP-conf-req SENT messages (less then 10)
- and then a Term-REQ:
- -> check whether your ISDN card is well configured
- it seems, that your machine doesn't dial
- (IRQ,IO,Proto, etc problems)
- Configure your ISDN card to print debug messages and
- check the /dev/isdnctrl output next time. There
- you can see, whether there is activity on the card/line.
- - there are at least a few RECV messages in the log:
- -> fine: your card is dialing and your remote machine
- tries to talk with you. Maybe only a missing
- authentication. Check your ipppd configuration again.
- - the ipppd exits for some reason:
- -> not good ... check /var/adm/syslog and /var/adm/daemon.
- Could be a bug in the ipppd.
-
---
-
-Q12: How can I reduce login delay?
-
-A: Log a login session ('debug' log) and check which options
- your remote side rejects. Next time configure your ipppd
- to not negotiate these options. Another 'side effect' is, that
- this increases redundancy. (e.g your remote side is buggy and
- rejects options in a wrong way).
-
-
-