home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Media Share 9
/
MEDIASHARE_09.ISO
/
bbs
/
cfos097f.zip
/
CFOS.DOC
next >
Wrap
Text File
|
1994-01-23
|
91KB
|
2,004 lines
FFFFFFFF
FF an ISDN CAPI FOSSIL driver
ccc FF ooooo sssss
cc FFFF oo oo ss by Martin Winkler &
cc FF oo oo ssss Christoph Lueders
ccc FF ooooo ss
ssssssssssssssssssssssss from Zaphods BBS, Bonn/FRG
--- Documentation ---
cFos, Version 0.97f, Release date 23-Jan-1994
0. Distribution Files
README Einfuehrung
REGISTER.DOC Wie erhalte ich eine registrierte Version?
COPYING.CF Nutzungsbedingungen
WHATSNEW Was hat sich geaendert?
CFOS.DOC Diese Dokumenation
MODEM.DOC Uebersicht ueber die "Modem" Kommandos
CFOS.FAQ Frequently asked questions zu 'cFos'
CFOS.EXE 'cFos' executable
1. Einfuehrung :
'cFos' ist ein FOSSIL Treiber, der mittels eines Modememulator
mit AT Command Set und unter Zuhilfenahme eines CAPI Treibers,
nach Version 1.1, Profil A eine grosse Anzahl an existierender
Software auch fuer ISDN nutzbar macht.
Da ISDN mehr ist, als nur ein Netz fuer High-Speed
Datenuebertragung, ist es unser Ziel, moeglichst viele
Moeglichkeiten des ISDN durch 'cFos' auf einfache Weise
zugaenglich zu machen.
'cFos' gibt es auch in einer registrierten Version, die man bei
uns lizensieren kann. Zeilen, die mit einem {+} gekennzeichnet
sind, beziehen sich auf diese registrierte Version. Weiteres
ueber diese "geheimnisvolle" registrierte Version steht in
REGISTER.DOC.
'cFos' braucht mindestens einen 286er AT Class Computer.
2. Features at a glance:
* Laueft mit jeder Karte, die ein ISDN CAPI, V1.1, Profil A hat.
* Unterstuetzt FOSSIL, Revision 5 (nach FSC-0015) mit einigen
Erweiterungen.
* Unterstuetzt mehrere B-Kanaele gleichzeitig, wahlweise mit
automatischem Ringdown. MultiPort Mode.
* Laueft alleine oder in Zusammenarbeit mit "standard" RS-232
FOSSILs.
* Eingebauter BIOS-Emulator, sodass auch Programme, die nur INT
14 unterstuetzen, betrieben werden koennen.
* 'cFos' ist schnell! Man erreicht bei Windowsizes >= 2 Daten-
uebertragungsraten bei X.75 von 7900 cps pro Kanal und mehr.
* 'cFos' enthaelt einen Modem-Emulator, mit dem nicht nur alle
Modem-Meldungen und Kommandos nachgebildet werden koennen,
sondern auch alle ISDN-spezifischen Parameter eingestellt,
gespeichert und damit ueberhaupt erst genutzt werden koennen.
* 'cFos' kann eine Statuszeile anzeigen, in der alle ISDN
Verbindungsparameter angezeigt werden und zusaetzlich "Modem
LEDs" fuer Carrier Detect, Off Hook, Transmit Data, Receive
{+} Data. In der registrierten Version wird die Dauer der der
aktuellen Gebuehreneinheit zusaetzlich noch angezeigt (Toll
Saver).
* Unterstuetzung fuer SPV's (semipermanente Verbindungen).
* Unterstuetzung fuer fast alle B2 und B3 Protokolle, z.B. X.75
und V.110.
* Unterstuetzt TELES Channel bundling protokoll, 128kbps ueber 2
B-Kanaele.
* Safety inactivity und connect timers, um den Gebuehren-"GAU"
zu verhindern. 'cFos' enthaelt speziellen Code, um evtl. auf-
tretende Fehler im CAPI/ISDN-Netz abzufangen.
* Die Time/Date Info des ISDN kann ausgewertet werden und danach
{+} die lokale Rechnerzeit. Zusaetzlich kann die Uhrzeit eines
NetWare Servers gesetzt werden.
* 'cFos' kann UMBs benutzen, um seine Daten abzulegen.
{+} * 'cFos' hat nun eigenes CHANNEL BUNDLING !
Das 'cFos' eigene Channel Bundling (CCB) ist herstellerunab-
haengig und unterstuetzt bis zu 4 B-Kanaele - auch mit
mehreren ISDN Karten gleichzeitig. Darueberhinaus laesst es
sich beliebig mit dem MultiPort Mode kombinieren, z.B. 2 Ports
buendeln gleichzeitig je zwei Kanaele. 'cFos' schafft mit zwei
B-Kanaelen 15800 CPS !!!
Das '{+}' Symbol weist auf Funktionen hin, die nur in der
registrierten Version verfuegbar sind.
3. 'cFos' Command Line Parameter
'cFos' kennt folgende Commands :
i Install.
Installiert 'cFos' als TSR im PC Speicher; dazu muss
natuerlich schon das CAPI geladen sein (wird angewarnt,
falls nicht). Alle Switches muessen beim Laden angeben
werden. Spaeteres Aufrufen wirkt nur bei speziellen
Commands (z.B. 't' oder 'bps').
d Deinstall.
Deinstalliert 'cFos' und gibt damit auch allen Speicher von
'cFos' wieder frei. Bitte ERST 'cFos' und DANN das CAPI
deinstallieren. Mit dem Deinstallieren werden alle
bestehenden Verbindungen, die ueber unser FOSSIL laufen,
getrennt.
r Reregister.
Re-registriert 'cFos' am CAPI. Damit kann das CAPI neu
initialisiert werden. Auch hier werden alle Verbindungen
getrennt. Mit diesem Aufruf werden einige CAPI-Strukturen
wieder neu initialisiert.
t Tranx.
Synchonisation der Rechner-Uhr mit der Zeit, die im ISDN
verfuegbar ist. Fuer eine weitere Erlaeuterung siehe weiter
unten.
{+} bps Baud (Bit per second).
Die Baudrate der z.Z. laufenden Verbindung wird in die
Environment Variable BPSRATE geschrieben. Auf diese Weise
steht sie zur Auswertung in Batch Files (z.b. beim Aufruf
von BBS Software) zur Verfuegung. Hinter dem Kommando kann
die Portnummer angegeben werden, z.B. 'cfos bps:2'.
reboot
Die FOSSIL Definition sieht eine Reboot Funktion vor, die
auch auf der Commandline verfuegbar ist. Vor dem Rebooten
werden erst die offenen Files aller DOS Applikationen
geschlossen, dann werden die Cache Buffers folgender Caches
geflushed: QCache, Super PC Kwik, PC Tools PC-Cache 5.x &
6.x, Qualitas Qcache 4.00, Norton Utilities NCACHE,
SMARTDRV v4.00+ und HyperDisk 4.50+. Danach wird der
Rechner via Keyboard Controller gebootet.
und folgende Switches :
-b Maximale B2-Framelen
Maximale im Modem-Emulator anwaehlbare B2-Framelen, Default
= 2048 Bytes
-w Maximale Windowsize
Maximale im Modem-Emulator anwaehlbare B2-Windowsize,
Default = 2
Mit diesen beiden Optionen wird festgelegt, wieviel Speicher
beim Installieren fuer das CAPI reserviert wird. Mittels
ATS22=xxxx und ATS26=x kann danach natuerlich auch ein kleinerer
Wert fuer die naechste Verbindung eingestellt werden, allerdings
kein groesserer.
-c Portnummer (Default 0)
(default 0, ein Port), 0 = COM1, 1 COM2, ... -c kann
mehrfach angegeben werden. Diese Einstellung der Ports
ermoeglichst das Zusammenspiel von 'cFos' mit einem RS232
FOSSIL auf einem Rechner.
'cFos' ueberprueft bei jedem INT 14h Aufruf, ob es diese
Port Nummer unterstuetzen soll. Falls nicht, wird der
"darunter liegende" INT 14h aufgerufen. Laedt man vor
'cFos' ein RS 232 Fossil, kann dieses den entsprechenden
RS-232 Port betreiben.
-e Enable BIOS emulator (Default 1)
0 = Off, 'cFos' arbeitet nur als FOSSIL.
1 = On, 'cFos' arbeitet als FOSSIL und als BIOS INT 14h
damit koennen auch Programme, die zwar kein FOSSIL,
aber BIOS INT 14h benutzen, ISDN betreiben.
2 = Force on, 'cFos' arbeitet nur als BIOS Emulator.
Empfehlung fuer Programme die BIOS INT 14h auf PS/2
Rechnern, oder andere INT 14h Erweiterungen benutzen.
Es werden die INT 14h Funktionen 4-1B deaktiviert.
Bemerkung: Da 'cFos' zur Zeit die '+++' Sequenz zum
Auflegen nicht unterstuetzt, legt die "set baudrate" BIOS
Funktion (INT 14h) auf - allerdings nur, wenn der
BIOS-emulator auf on geforced wurde (-e2). Das ist ausser
der FOSSIL Funktion 6 (raise/lower DTR), die einzige
Moeglichkeit aufzulegen.
-f fast-event, Einstellung der Datenreceiver-Strategie.
1 = Das Kopieren der Daten in den FOSSIL Receiverbuffer
uebernimmt die Applikation
Vorteil : Man braucht fast keinen Speicher mehr fuer
den FOSSIL Receiver Buffer
Nachteil : Bei langsamen Applikationen kann die
Uebertragunsgeschwindigkeit etwas sinken.
0 = Das Kopieren der Daten in den FOSSIL Receiverbuffer
uebernimmt der CAPI-Eventhandler (default)
Vorteil : Leichte Speedvorteile bei langsamen Applika-
tionen
Nachteil : Man brauch einen entsprechend grossen FOSSIL
Receiver Buffer.
-r rxbufsize, Groesse des Receiverbuffers
Falls 'cFos' mit -f0 geladen wurde, ist die Default-Groesse
gleich B2-Framelen * (Windowsize + 1) Bytes. Laedt man
'cFos' mit -f1, ist hier der Default 256 Bytes.
-t txbufsize, Groesse des Transmitterbuffers
Default ist B2-Framelen * (Windowsize + 1) Bytes.
-v CAPI Interrupt Nummer, default 0xF1 = 241.
{+} -a Auxiliary Port, samt Controller Nummer (z.B. -a1).
Fuer die registrierte Version von 'cFos' kann man so fuer
'cFos' Channel Bundling (CCB), d.h. Datenuebertragung auf
mehreren ISDN B-Kanaelen gleichzeitig, sogenannte Auxiliary
Ports aktivieren.
Wird hinter einer Zahl ein 'k' angegeben, wird der Wert in K
(=1024) gerechnet. -r4k bedeutet z.B. 4096 bytes Receiverbuffer.
Alle Werte koennen auch in Hex angegeben werden, dazu muss nur
ein '0x' vor die Zahl, also z.B. 0x800 fuer 2048.
zusaetzliche -j Flags:
-j3 Disable 386er Support.
-jc Carrier LED. Hierbei wird die sCrollLock LED als Carrier
LED missbraucht. Solange eine Verbindung besteht, ist diese
LED an und solange ein einkommender Ruf weder angenommen
noch abgelehnt ist, blinkt sie. Vorsicht bei Programmen,
die ScrollLock fuer andere Zwecke benutzen (z.B. das
FrontDoor Terminal); diese springen darauf dann auch an.
{+} -jd Data Dump. Wenn dieses Flag angegeben ist, protokolliert
'cFos' alle empfangenen und alle gesendeten Daten in eine
Datei namens FOSSDUMP, die dann in dem Verzeichnis zu
finden ist, in dem sich auch CFOS.EXE befindet. Das dumpen
wird erst mit dem Deinstallieren des FOSSILs wieder
gestoppt. Der Data Dump benoetigt zusaetzlich 10kb
Hauptspeicher.
-je Disable environment deallocation. Sollte beim oder direkt
nach dem Laden von 'cFos' ein Absturz oder schwerwiegender
DOS Fehler auftreten, koennte dieser Switch Abhilfe
schaffen.
-ji Laedt 'cFos' mit initialisierten COM Ports. Fuer Software,
die vergessen sollte, die COM Ports vor Benutzung zu
initialisieren.
-jn Disable NetWare support. Wenn dieser Switch angegeben wird,
wird kein Versuch gemacht, NetWare zu finden oder zu
unterstuetzen.
-jp Aktiviert passiven Ebene 3 Verbindungsaufbau, um auch den
Eigenheiten des ISDN Blaster FOSSILs PCIF Version 5.78
gerecht zu werden (Empfehlung fuer Stollmann und AVM, nicht
aber fuer TELES). Sollte bei gegenseitigem PCIF 5.81 (oder
hoeher) nicht mehr noetig sein.
-jr Disable CAPI Re-Register (noetig fuer SOLIS Karten).
-js Ignore seconds in ISDN date/time. Siehe 'TRANX'.
-ju UMB Speicherbloecke nicht benutzen. Ansonsten versucht
'cFos', Datenbloecke erstmal im XMS oder UMB abzulegen.
-jv Disable V.110. Damit weiss 'cFos', dass das jeweilige CAPI
kein V.110 unterstuetzt und gibt z.B. bei ATB1 und ATB2
einen Fehler aus. Ebenso werden Rufe, die V.110 mittels
Additional Service Indicator signalisieren, abgelehnt. (s.
auch Kapitel 6)
-jx Dieser Switch veranlasst 'cFos', bei der Funktion 0x1b die
gleichen Werte in CX und DX wie X00 zurueckzugeben.
Erforderlich, um mit XBTX zu arbeiten, ansonsten raten wir
aber von der Benutzung dieses Switches ab.
-d[df] Debugging Trace
Wenn diese Switches beim Laden angegeben werden, schreibt
'cFos' eine debug-trace von allen CAPI-Messages mit. Dafuer
belegt es 10kb zusaetzlichen Speicher als Buffer und schreibt
diesen bei Bedarf auf Platte. Das File heisst CTRACE und liegt
in dem gleichen Verzeichnis wie CFOS.EXE. Das File kann
schnell sehr gross werden, daher sollte man diese Funktion nur
in seltenen Faellen benutzen.
Mit -d schaltet man nur das Mitschreiben der CAPI-Messages
ein, mit -dd wird noch mehr mitgeloggt und mit -df oder -ddf
werden noch zusaetzlich fast alle FOSSIL Aufrufe mitgeloggt.
Sollte sich 'cFos' auf Ihrem Rechner sonderbar verhalten,
nicht sauber laufen, keine einkommenden Rufe annehmen oder
aehnliches, ist es immer gut, uns von dem Problem ein Trace
mitzuschicken. Dazu sollte 'cFos' mit 'cfos i -dd' geladen
werden und danach auf jeden Fall mit 'cfos d' wieder
deinstalliert werden, bevor das CTRACE verschickt oder
eingepackt wird.
Tranx
Beim aktiven Verbindungsaufbau und bei jedem Verbindungsabbau
schickt ISDN dem Teilnehmer die aktuelle Zeit (inklusive
Sommer/Winterzeit gestellt nach der TU Braunschweig;
allerdings ist dieser Service ab Anfang 1994 kostenpflichtig).
'cFos' vergleicht diese Zeit mit der Rechneruhr und stellt
fest, um wieviel sich beide Zeiten unterscheiden, stellt die
Rechneruhr allerdings nicht sofort, sondern erst auf Anfrage.
Wenn man 'cFos' mit der Option 'T' aufruft, holt sich das
aufgerufene 'cFos' diese Zeitabweichung von dem residenten
'cFos' (welches seinen alten Wert danach auf 0 setzt) und
setzt die Rechneruhr auf den korrigierten Wert. Die Uhrzeit
kann auch aus dem Modem-Emulator gesetzt werden mit dem
Kommando AT&T.
Diese Art und Weise ist wesentlich einfacher und
unbedenklicher zu implementieren als jedesmal eine Verbindung
aufzubauen, wenn 'cFos' mit 'T' Option aufgerufen wird. Es hat
allerdings den Nachteil, dass es nur die Uhrzeit setzt, wenn
seit dem letzten 'cfos t' Aufruf Verbindungen vorhanden waren.
Soll die Uhrzeit immer gesetzt werden, einfach ein 'at&t' in
den Modem Init-String schreiben.
Anmerkung: in manchen Ortsnetzen wird die Zeit ohne Sekunden
uebermittelt. 'cFos' ist so geschrieben, dass es sich dann
innehalb mehrerer Verbindungen an die "richtige" Uhrzeit
annaehert. Dieser Modus kann auch forciert werden, dann wird
das Sekundenfeld ignoriert, selbst wenn eines mit uebermittelt
wurde. Dies kann bei lokalen Telephonanlagen sinnvoll sein.
Wird ein NetWare Server erkannt, so wird dessen Zeit auch
gesetzt, solange kein -jn Switch angegeben wurde. Allerdings
muss der entsprechende User dafuer File Server Console
Operator sein, d.h. im SYSCON unter 'Supervisor Options',
'File Server Console Operators' als ein solcher eingetragen
sein.
4. AT Command Emulator :
Da dieser Treiber ermoeglichen soll, bestehende Software mit
ISDN zu benutzen, emuliert 'cFos' ein Modem, das Kommandos wie
'ATD' zum Waehlen und 'AT&V' zum Anzeigen der Konfiguration
benutzt. Die gesamte Steuerung des CAPI's und des Verhaltens von
'cFos' geschieht ueber den Modem Emulator.
Der Emulator besitzt eine kleine Hilfe, die mit 'AT?' angezeigt
werden kann. Eine komplette Aufstellung aller Kommandos und
Register findet sich in der Datei MODEM.DOC.
Der Receiver-Buffer muss gross genug sein, um den jeweiligen
Output des AT Command Emulators zu fassen; z.B. sollte er ca.
2kb gross sein, um eine ganze 'AT?' Screen fassen zu koennen.
Stellt man den rx-Buffer beim Laden von 'cFos' zu klein ein (mit
-r oder -f1), dann kann bei einigen Ausgabe des Modem Emulators
ein 'rx-buffer too small, output lost' erscheinen.
Es ist manchmal etwas schwierig, eine neue und wesentlich
komplexere Technik wie ISDN in das teilweise recht simple Bild
von einem Modem mit seinen Commands und Result Codes zu
quetschen, deshalb hier eine Erklaerung, was die Modem Messages
bedeuten:
- NO ANSWER
Heisst, dass die Gegenstelle nicht abgenommen hat, aber der
Ruf quasi "bis zu ihrer Telephondose" gekommen ist. Es faellt
nur ein 1.TR.6 Cause darunter:
0x34ba: No user responding
- NO DIALTONE
Heisst, dass 'cFos' nicht bis zu der Gegenstelle durchkommen
konnte, und das der Grund dafuer wahrscheinlich beim Anrufer
liegt. Gruende waeren:
0x3301: Fehler beim Aufbau D-Kanal Ebene 1
0x3302: Fehler beim Aufbau D-Kanal Ebene 2
0x3305: Abbruch D-Kanal Ebene 1
0x3306: Abbruch D-Kanal Ebene 2
0x3307: Abbruch D-Kanal Ebene 3
0x348a: No channel available
0x34a0: Outgoing calls barred
0x34d9: Nonexistent CUG
0x34f0: Network congestion
0x34a3: Local procedure error
- BUSY
Heisst, dass wir schon bis zu der Gegenstelle gekommen sind,
diese aber entweder aus Ueberlastung oder aktivem Ablehnens
unseren Anruf nicht annehmen will. Das waere:
0x34a1: User access busy
0x34bb: User busy
0x34bd: Incoming calls barred
0x34be: Call rejected
- NO CARRIER
Alle anderen Causes, die einen Connect-Versuch scheitern
lassen. Falls hier jemand der Meinung ist, dass ein Cause noch
in eine der o.g. Klassen gehoert, bitte melden. Einen Cause
meinen wir noch dingfest gemacht zu haben: 0x3483, der kommt,
wenn man eine analoge Nummer anruft, waere also mit einem
VOICE zu vergleichen, ist aber bisher nicht eingebaut.
Ansonsten gibt es z.B.
0x34b5: Destination not obtainable (z.B. "Kein Anschluss
unter dieser Nummer" ;-) oder unzulaessige
Dienstmerkmale.
0x34f1: Remote Procedure Error (bei der anrufenden Seite
liegt ein Fehler vor, z.B. unzulaessiger AddSi)
Der Modem-Emulator kann noch eine ganze Reihe andere Commands,
die man bitte dem AT Command-Chart in MODEM.DOC entnehmen moege.
Gesondert seien hier noch ausfuehrlich die ATIn Commands
erwaehnt:
Mit ATI0, ATI1, ATI2 und ATI4 koennen mit dem Modem-Emulator
Informationen ueber die letzte Verbindung abgefragt werden:
- ATI0 product-info
- ATI1 'cFos' Status Zeile (s. Kapitel 7)
- ATI2 Link Information :
Bei "Last inbound call" wird die CallerId, der Requested
Service Indicator und der Requested Additional Service
Indicator sowie die requested EAZ des letzten Anrufers
angezeigt.
Bei "Last outbound call" wird unter "Charge" die Anzahl der
Gebuehreneinheiten des letzten Anrufs angezeigt. Bei "Last
disconnect" wird zum einen der Grund des letzten disconnect
angegeben, zum anderen der Reason, den die CAPI messages beim
passiven (!) disconnect an 'cFos' melden.
"Last disconnect" kann folgende Werte enthalten :
Active :
'cFos' wurde von der Applikation aufgefordert zu
disconnecten.
Passive :
die Gegenseite oder das CAPI hat aufgelegt.
Disconnect B3 timeout :
Der safety timer (s. oben) wurde aktiviert.
Disconnect D timeout :
Der safety timer (s. oben) wurde aktiviert.
CAPI reset :
Der safety timer (s. oben) wurde aktiviert und es wurde als
letzte Massnahme ein CAPI Reset durchgefuert, (s. oben).
Connect timeout :
Die in S7 angegebene Zeit beim Verbindungsaufbau wurde
ueberschritten.
Inactivity timout :
Die in S19 angegebene Zeit wurde nichts uebertragen.
- ATI4 Message Dump:
zeigt die letzten 10 gespeicherten CAPI Messages an, die
W-Elemente nach 1TR6 enthalten, ausser der Date/Time- und der
Charging-Information. Auf diese Weise koennen z.B. die letzten
CallerIDs derjenigen angezeigt werden, die waehrend einer
Verbindung "angeklopft" haben.
Profile saving:
Bei einem normalen Modem werden die Settings mit AT&W in das
NVRAM des Modems geschrieben und dort bei einem ATZ auch
wieder ausgelesen. Da 'cFos' kein NVRAM hat, werden die
Settings in einer Datei auf der Platte gespeichert. Diese
Datei liegt bei DOS 3.1+ in dem Verzeichnis, in dem auch
'cFos' liegt, bei DOS <3.1 im dem Verzeichnis, welches bei
Aufruf von 'cFos' aktuell war.
Das File heisst PROFILE und enthaelt alle Profiles, die man
mit 'AT&Wn' abgespeichert hat (n=0..9). Ein entsprechender
'ATZn' holt das Profile wieder zurueck. Wenn keine Nummer
angegeben wird, dann speichert/restauriert 'cFos' unter/von
Nummer 0.
Da fuer das Lesen und Schreiben dieser Datei DOS benoetigt
wird, muss 'cFos' anhand z.B. des "DOS critical flags"
pruefen, ob zur Zeit DOS Zugriffe erlaubt sind. Wenn nicht,
speichert bzw. laedt es das Profile auch nicht und meldet
schlicht "ERROR". Ist das Profile nicht gueltig (z.B. wenn es
von einer aelteren 'cFos' Version angelegt wurde) wird
ebenfalls "ERROR" gemeldet. Ist kein Profile vorhanden,
bewirkt ein ATZ da gleiche wir AT&F und meldet "OK".
Achtung! Wenn 'cFos' mit mehreren Ports benutzt wird, kann
natuerlich auf diese Art und Weise leicht das gleiche Profile
fuer alle Ports benutzt werden (wenn alle mit 'ATZ'
initialisiert werden). Um das zu vermeiden, sollte man einfach
verschiedene Nummern fuer die 'ATZ's vergeben (ATZ0...ATZ9).
Bei mehreren Ports werden die Register
S13 Serviced EAZ Mask
S14 Serviced SI Mask
S40 Controller
S41 Info-Mask-low
S42 Info-Mask-high
"gemirrored". Das heisst, wenn ein Port diese Register
aendert, dann sind sie auch automatisch fuer alle anderen
Ports veraendert. Das geht nur so, da diese Werte immer fuer
alle Ports gelten und nicht fuer einen einzelnen. Das ist
durch das CAPI bedingt.
5. Aktiver Verbindungsaufbau, V.110, Channel Bundling (128k bps)
Neben der Telefonnummer koennen bei einem Verbindungsaufbau im
ISDN diverse Parameter eingestellt werden, um Service und
verschiedene Uebertragungsprotokolle auszuwaehlen. 'cFos' ist
defaultmaessig auf Datenuebertragung mit X.75 als Ebene 2
Protokoll und transparentem, d.h. nicht vorhandenem, Ebene 3
Protokoll eingestellt. Alle noetigen Parameter koennen von Hand
in den Registern S16-S18, S20-S36, S39 und S40 eingestellt
werden.
Um die Auswahl der wichtigsten Datenuebertragungsprotokolle
moeglichst einfach zu gestalten, kann man mit AT Befehlen die
folgenden Protokolle einstellen:
ATB0 Datenuebertragung mit X.75 und transparentem B3 Protokoll,
wobei abweichend vom CAPI-Default, die X.75 Windowsize und
Framelength auf die Werte gesetzt werden, mit denen 'cFos'
geladen wurde (Optionen -w und -b). Der Additional Service
Indicator wird auf 0 gesetzt.
ATB1 Datenuebertragung mit V.110 und transparentem B2/B3
Protokoll, 38400,8,n,1,asynchron. Der Additional Service
Indicator wird auf 64 (40 hex) gesetzt.
ATB2 Datenuebertragung mit V.110 und transparentem B2/B3
Protokoll, 19200,8,n,1,asynchron. Der Additional Service
Indicator wird auf 199 (C7 hex) gesetzt.
ATB3 Wie ATB0, aber mit Channel- Bundling ( 128k bps). Unter-
stuetzt nur TELES channel bundling, NICHT das 'cFos'
channel bundling, welches mit AT&Bn aktiviert wird. Ist
nur dann verfuegbar, wenn BUNDLE.EXE in STARTS0 geladen
wurde.
ATB4 ELINK Mode,
Datenuebertragung mit X.75 und transparentem B3 Protokoll,
wobei abweichend vom CAPI-Default die X.75 Windowsize auf
7 und die Framelength auf 256 Bytes gesetzt wird, falls
'cFos' mit -w7 und mindestens mit -b256 geladen wurde.
Ansonsten liefert ATB4 einen Error. Der Additional Service
Indicator wird auf 146 gesetzt.
ATB5 BTX Mode. Da fuer BTX eine Variante des X.75 Protokolls mit
Window-Size 7 benutzt, muss 'cFos' mit -w7 geladen worden
sein, sonst liefert dieses Kommando einen "ERROR".
Wir empfehlen, diese AT Befehle fuer den Verbindungsaufbau zu
benutzen. Man kann aber auch den Verbindungsaufbau durch Setzen
der einzelnen Register fuer spezielle Anwendungen anders
einstellen. Bei manchem Equipment muss man z.B. den Additional
Service Indicator immer auf 0 stellen, sonst nimmt die
Gegenseite ueberhaupt nicht ab (z.B. wenn man CompuServe anrufen
will).
Hier noch ein Modem INIT String fuer spezielle Anrufe:
ATB0S20=8S27=237 fuer CompuServe und Datex-P Gateways
V110, 9600,ansync,7,E,1
6. Passiver Verbindungsaufbau und automatische Protokollauswahl.
Zunaechst muss man dem CAPI durch Setzen der "Serviced SI Mask"
"sagen" auf welche ISDN Services und welche EAZs es ueberhaupt
"hoeren" soll. Die Services stellt man mit Register S14 ein. Bit
7 = 1 aktiviert beispielsweise eingehende Rufe mit Dienst-
erkennung "Datenuebertragung". Bit 1 = 1 aktiviert Rufe fuer
"Telefondienst". Die aktiven EAZs kann man entweder durch die
entsprechenden Bits in Register S13 setzen oder mit AT&Lxxxx
einstellen. AT&L* aktiviert alle EAZs. AT&L123 die EAZs 1, 2 und
3.
'cFos' kennt z.Z. die Dienste "Datenuebertragung" und
"Telefondienst". Aktiviert man Rufe mit anderer Dienstkennung,
waehlt 'cFos' bei unbekanntem Dienst (Service) die Protokolle
und Parameter gemaess der Register S20-S36.
Bei eingehenden Rufen mit Dienstkennung "Telefonie" waehlt
'cFos' als B2 Protokoll "Bittransparent" und als B3 Protokoll
"Transparent". Somit bekommt man einen Datenstrom mit konstanten
8000 cps mit digitalisierten Analog-Samples. Defaultmaessig ist
aber nur "Datenuebertragung" als Service aktiviert.
Bei eingehenden Rufen mit Dienstkennung "Datenuebertragung" hat
'cFos' aufgrund des Design des CAPI nur die Moeglichkeit, anhand
des Additional Service Indicators die Uebertragungs-Protokolls
auszuwaehlen. Eine nachtragliche automatische Aenderung des
Protokolls ist nicht moeglich, da es keine
Signalisierungsmoeglichkeit fuer das CAPI gibt, mit der es die
Protokolle des Anrufers anzeigen koennte, geschweige denn die
dazugehoerigen Parameter.
Das B3 Protokoll ist immer das in den Registern S21 und S30-S36
voreingestellte, also am besten "Transparent". Das CAPI default
1 (=T.70 NL) wird von fast keiner Mailbox benutzt.
Das B2 Protokoll wird anhand des Additional Service Indicators
gemaess 1.TR.6 ausgewaehlt.
Fuer V.110, 38400 bps, asynchron ist nach 1TR6 ueberhaupt kein
Additional Service Indicator vorgesehen. Dieses Protokoll
koennen Anrufer bei 'cFos' mit dem Additional Service Indikator
64 bzw. 128 auswaehlen.
Aufschluesselung des Additional Service Indikator :
0000 0000 Anrufer wuenscht X.75, 64000 bps
1000 0000 Anrufer wuenscht V.110, 38400,8,n,1,asynchron
01-- -000 Anrufer wuenscht V.110, 38400, asynchron
1010 ---- Anrufer wuenscht V.110, X.30 (ECMA 102), synchron
1011 ---- Anrufer wuenscht V.120, synchron
11-- ---- Anrufer wuenscht V.110, X.30 (ECMA 102), asynchron
die zwei wichtigsten :
1100 0111 Anrufer wuenscht V.110, 19200,8,n,1,asynchron
0100 0000 Anrufer wuenscht V.110, 38400,8,n,1,asynchron
Ob diese Protokolle vom jeweiligen CAPI unterstuetzt werden,
haengt vom Hersteller des CAPI ab. 'cFos' waehlt "V.110 mit
transparentem B2-Protokoll" (8).
Anrufer, die sich nicht an diese Spezifikation halten, oder mit
Telefonanlagen arbeiten, die den Additional-Service Indikator
filtern, bekommen es leider u.U. mit mit einem anderen
Protokoll, als dem gewuenschten Protokoll zu tun.
Da es mit der Protokoll-Auswahl so viele Probleme gibt, haben
wir noch ein paar "Specials" in 'cFos' eingebaut:
Ist 'cFos' der Additional Service Indicator gaenzlich unbekannt,
entscheidet Register S43, welches Protokoll selektiert wird. Das
High-Byte selektiert das Protokoll, das Low-Byte ggf. die V.110
User-Rate. Als Default ist Register S43 auf V.110, 38400,8,n,1,
asynchron eingestellt, da es mit diesem Modus am meisten
Probleme zu geben scheint.
Zusaetzlich kann man einzelne EAZs auf bestimmte Protokolle
festlegen, falls der Additional Service Indicator gleich 0 ist.
Dies geschieht mit den Registern S50-S59 fuer die EAZ 0 bis EAZ
9. Ist das Low-Byte des entsprechenden Registers ungleich Null,
wird die EAZ auf das Protokoll festgelegt, das im High-Byte des
Registers angegeben ist. Das Low-Byte bestimmt dann ggf. die
V.110 User Rate. Ist der Additional Service Indicator ungleich
0, bestimmt obige Aufschluesselung nach 1.TR.6 das Protokoll.
Defaultmaessig ist dieses Feature nicht aktiviert.
Beispiel:
Seien S51 = 0x0 und S52 = 0x0840 und S53 = 0x08C7 und die
Serviced EAZ Mask = 14 (man hoert also auf EAZ 1-3); dann
werden die Protokolle wie folgt selektiert :
EAZ AddSi = 0 AddSi <> 0
1 X.75 gemaess 1.TR.6
2 V.110,38400 gemaess 1.TR.6
3 V.110,19200 gemaess 1.TR.6
Also:
Anrufer, die X.75 wollen, koennen auf EAZ 1 anrufen.
Anrufer, deren ISDN Karten 1.TR.6 konform sind und die
V.110 wollen, koennen auf allen EAZs anrufen.
Anrufer, deren ISDN Karten nicht 1.TR.6 konform sind,
koennen fuer 38400 auf EAZ 2 anrufen und fuer 19200 auf
EAZ 3.
7. Status Line:
'cFos' kann eine Status-Zeile auf dem Bildschirm darstellen, um
etwas "Modem-Feeling" zu geben, bzw. fuer Debug-Zwecke.
AT&D0 Status-Zeile aus
AT&D1 Status-Zeile ein, wenn Port initialized ist
AT&D2 Status-Zeile ein, wenn eine Verbindung aktiv ist
ATS11=xx Bildschirmzeile, in der die Status-Zeile dargestellt
wird (faengt bei 0 an zu zaehlen).
Sie ist folgendermassen aufgebaut:
Anzahl der Frames, die noch ausstehen.
|
| Anzahl Frames die gerade gesendet werden
| |
{+} | | verbleibende Sec. der aktuellen Einheit
| | |
cFos> C-B3 ACOD 0R:64 0T:1024 C:12 V110 19200 9111041 39
| | |||| | | | | | |
connect/ | |||| | | Charge | | Caller ID/
disconnect | |||| | | (Gebuehren- | | dialed number
indicator | |||| | | Einheiten) | |
(*) | |||| | | | bps rate bei V110
Ebene |||| | | B2-Protocol (z.b. X75)
|||| | last transmitted block length, mit TX-"LED"
|||| last received block length, mit RX-"LED"
Auto-Ans|||
||DTR-"LED" (bei DTR low werden alle Calls rejected)
Carrier Detect|
Offhook-"LED", an = reject calls (anders als beim modem)
Evtl. kann vor dem "R" noch eine Zahl "auftauchen", die dann
angibt, wieviele Datenbloecke 'cFos' dem CAPI noch nicht
quittiert hat. Vor dem "T" kann ebenfalls noch eine Zahl stehen,
die angibt, wieviele Datenbloecke z.Z. unterwegs zum Empfaenger
sind.
(*) waehrend einer laufenden Verbindung wird hier die Anzahl der
aktiven B-Kanaele angezeigt ("B3-1")
{+} Bei 'cFos' Channel Bundling (CCB) kann hier z.B. "B3-2" stehen.
8. Safety/Debug features :
Zu Anfang etwas gewoehnungsbeduerftig bei ISDN-Karten ist
vielleicht, dass man nie so recht weiss, ob die Verbindung noch
steht, oder hoffentlich aufgelegt ist.
'cFos' kann auf mehrere Arten den "Gebuehren-GAU" verhindern:
1. Verfuegt der Modem-Emulator ueber einen Inactivity Timer.
Mittels ATS19 kann eingestellt werden, wie lange sowohl
nichts mehr empfangen als auch gesendet werden darf, bevor
automatisch aufgelegt wird.
2. Beim Abbau der Verbindung laufen Timer, die ueberwachen, ob
vom CAPI die entsprechenden DISCONNECT_B3_IND bzw.
DISCONNECT_IND Messages signalisiert wurden. Geschieht dies
nicht, wird zweimal im 5 sec. Takt erneut zuerst zweimal die
Ebene B3 disconnected, danach zweimal die Ebene D. Fuehrt
auch dies nicht zum Erfolg, meldet sich 'cFos' vom CAPI ab
und danach erneut an. Spaetestens jetzt sollte das CAPI alle
bestehenden Verbindungen abgebaut haben.
3. Beim Connect gibt es, wie bei Modems einen "Wait for Carrier"
Timer. Kann innerhalb der in S7 einstellbaren Zeit die
Verbindung nicht aufgebaut werden, wird disconnected. Damit
soll "haengen" beim Aufbau der B3 Verbindung verhindert
werden.
4. 'cFos' unterstuetzt in der DEBUG-Version einen alternate
Monitor. Man kann dann auf dem alternate Monitor alle CAPI
message und einigen Hand-DEBUG Output verfolgen. Das kann im
Zweifel sehr hilfreich sein, wenn man beobachten kann, wo
genau Probleme auftauchen.
9. Ueber Blockgroessen und Speicherbedarf
Es existiert eine verwirrende Vielfalt von Blocks und Buffers in
diesem FOSSIL Treiber. Hier ein Versuch einer Erklaerung:
B2-Framelength:
Daten werden im ISDN auf Ebene 2 in 'Frames', also
paketweise, verschickt. Diese Frames (=Pakete) haben eine
maximale Laenge. Das bezeichnen wir als B2-Framelength. Die
Spezifikation des CAPI erlaubt eine maximale B2-Framelength
von 2048 Bytes. Werden groessere Frames empfangen kann es zu
Datenverlusten und Abbruch der Verbindung kommen ! Damit sind
ISDN-Karten, die mit groesserer B2-Framelength senden zu CAPI
Anwendungen inkompatibel !!!
B3-Framelength:
Auch auf Ebene 3 werden Daten in Frames verschickt. Wenn Ebene
3 transparent ist (also kein Protokoll hat), dann sind die
B3-Frames genauso gross wie die B2-Frames.
Wenn allerdings auf Ebene 3 ein Protokoll gefahren wird, z.B.
T70.NL (CAPI default, aber nicht 'cFos' default), dann
benoetigt dieses Protokoll noch ein paar Bytes Overhead. Diese
Bytes sind allerdings aus der Sicht des B2-Protokolls normale
Nutzdaten und somit in einem entsprechenden Buffer zu
speichern.
Die B3-Framelength ist uebrigens die maximale Anzahl von
Bytes, deren Empfang durch eine DATA_B3_IND signalisiert
werden kann.
B2-Windowsize:
Die B2-Windowsize ist die maximale Anzahl von
B2-Datenbloecken, die das CAPI losschicken darf, ohne dass ein
Empfang von Daten von der Gegenseite bestaetigt werden muss.
Um "full-streamed" Datenuebertragung (d.h. die Datenbloecke
werden ohne Verzoegerung durch Warten auf die
Empfangsbestaetigung kontinuierlich verschickt) zu
ermoeglichen, sollte die B2-Windowsize auf mindestens zwei
stehen, sofern sich dies bei der Gegenseite auch einstellen
laesst (Ist dies nicht moeglich, kann u.U. die Gegenseite
"ueberrannt" werden.
Buffer fuer API_REGISTER
Das CAPI benoetigt mindestens einen Puffer fuer einkommende
B3-Datenbloecke. Dieser Puffer muss mindestens einen
B2-Datenblock samt B3 Overhead Aufnehmen koennen. Wenn also
B2=X.75 und B3=T70.NL eingestellt ist, dann benoetigt das CAPI
bei einer gewuenschten max. B3-Framelength von 128 Bytes eine
B2-Framelength von 130 Bytes und damit 130 Bytes fuer diesen
Puffer. Das CAPI muss allerdings die bei API_REGISTER
angegebene maximale Anzahl B2-Frames puffern koennen, die
wiederum abhaengig ist von der B2-Windowsize und der Anzahl
der B3-Verbindungen. Ausserdem braucht das CAPI fuer seine
Message-Queues ebenfalls Speicher. Somit ergibt sich in
unserem Beispiel bei API_REGISTER folgender Speicherbedarf
(Anzahl der Messages, die die Queues aufnehmen koennen sei
hier 10) :
(10 * 180) + (Anz. B3-Verbingungen * B2-Windowsize * 130)
Buffer fuer FOSSIL Funktionen
Das FOSSIL braucht auch noch Speicher fuer seine Ringbuffer.
Der Receiver-Buffer sollte mindestens so gross sein, wie die
B3-Framelength. Andernfalls kann 'cFos' dem CAPI den
empfangenen Datenblock nicht vollstaendig abnehmen. Der
empfangene Datenblock wird statt dessen gesplittet und in
mehreren Teilen in den FOSSIL Receiver Buffer geschrieben.
Dies kann zu geringfuegigen Verzoegerungen bei der Bearbeitung
der empfangenen Daten fuehren.
Weiterhin kann 'cFos' bis zu acht Messages vom CAPI "auf hold"
legen und in den Receiverbuffer kopieren, wenn dieser wieder
genuegend Platz hat. Das ist eine mehr als die maximale
B2-Windowsize nach CAPI. Voraussetzung dafuer ist allerdings,
dass das CAPI genuegend Empfangsspeicher hat.
Bei Senden versucht 'cFos' die Daten moeglichst sofort, aber
auch in moeglichst grossen Bloecken (und dabei moeglichst
viele auf einmal :-), also maximal B2-Windowsize viele) zu
verschicken. Durch die Art, wie mit dem CAPI durch
DATA_B3_REQ-Messages Daten verschickt werden, ergibt sich,
dass, um die Transmitterbuffer-Grenzen nicht zu
ueberschreiten, Daten, die nahe der Puffergrenzen liegen,
nicht immer in Bloecken der maximalen B3-Framelength
verschickt werden koennen. Um diesen Effekt zu minimieren
sollte die Groesse des Transmitterbuffers etwa B2-Framelength
* (Windowsize + 1) betragen.
{+} Beim Channel Bundling sollte diese Groesse noch mit der Anzahl
der B-Kanaele multipliziert werden.
10. Windowsizes, die ultimative Speed !
Man kann versuchen, durch moeglichst grosse B3 Datenbloecke, die
Geschwindigkeit zu erhoehen. Allerdings ist das nicht unbedingt
von Erfolgt gekroent. Das liegt an der Art und Weise, wie bei
X.75 Daten verschickt werden.
Die B2-Windowsize ist, wie oben erwaehnt, die Anzahl der Frames,
die sich gerade in Transmission befinden duerfen, ohne das eine
Confirmation fuer diese empfangen wurde. Das heisst, bei einer
Windowsize von drei kann man drei Blocks hintereinander (ohne
Pause!) verschicken ohne auf eine Bestaetigung warten zu
muessen.
Somit muss 'cFos' bei einer Windowsize von 1 immer auf die
Confirmation fuer den Block warten, bevor es einen neuen
verschicken darf. Nun werden aber wiederum die Confirmations
erst dann gemeldet, wenn die Applikation auf der Gegenseite der
dortigen ISDN-Karte den Datenblock abgenommen hat. (Das ist sehr
sinnvoll, da man so eine Art Flow-Control zwischen den beiden
Teilnehmern hat. Im ISDN gibt es kein RTS/CTS handshake :-) ).
Dadurch, dass bei einer Windowsize von 1 immer nur ein Block
unterwegs sein kann, bekommt ein ISDN-Transfer exakt das gleiche
Zeitverhalten, wie X-Modem.
Das ist Steinzeit-DFUE !!!
Bei einer Windowsize von 2 hingegen kann 'cFos', waehrend gerade
ein Block verschickt wird, schon den zweiten losschicken und die
Gegenseite, waehrend der zweite noch empfangen wird, schon den
ersten bestaetigen. Auf diese Weise koennen die Datenbloecke
nahezu ununterbrochen verschickt werden.
Damit kann man *wirklich* Speed erreichen. Wir haben bei unseren
Tests bei einer durchschnittlichen Blockgroesse von 2048 Bytes
mehr als 7900 cps (bei theoretischen 8000 cps) erreicht. Als
Mailerprotokoll wurde Z-Modem verwendet. Eine Erhoehung der
Windowsize auf 3 war wirkungslos.
Unsere Empfehlung:
Obwohl die Transfer Routinen in 'cFos' auf High-Speed
optimiert sind, halten wir eigentlich nichts von dem
CPS-Krieg, da es genau genommen auf die tatsaechliche
Uebertragungsdauer ankommt, denn die kostet Geld. Uebertraegt
man eine 2 MB grossen Datei mit 7500 cps statt mit 7900 cps,
macht das einen Unterschied von 15 sec. aus, kostet also im
Inland im schlimmsten Fall eine Einheit mehr.
Ein weiterer Faktor bei den Uebertragungsraten ist der
Protokoll-Overhead (den man aber bitte auch nicht
ueberbewerten sollte - viel kritischer ist das oben
beschriebene Zeitverhalten). Um diesen zu minimieren,
empfehlen wir B3-Protokoll=4, also transparent. D.h. der
Overhead ist hier Null. Um ebenfalls den B2-Protokoll Overhead
zu minimieren, empfehlen wir eine B2-Framelength von 2048
Bytes. Mit dieser Framelength sollten alle ISDN Karten beim
Empfang klarkommen, allein schon um zu potentiellen
CAPI-Karten kompatibel zu sein.
Wer seine ISDN-Karte auf eine groessere Framelength einstellt,
macht sich damit inkompatibel zu anderen !!! Leider verschickt
z.B. die ISDN-Blaster defaultmaessig 16k Frames, weshalb mit
diesen Karten ohne Umstellung kein Transfer moeglich ist. Aber
es gibt einfache Abhilfe: einfach ein ATS75=0x0800 in den
Init-String und die Blaster schickt nur noch max. 2k Frames.
Wer keinen CONNECT zu einer ISDN-Blaster hinbekommt, versuche
V.110 und schreibe dem entsprechenden Betreiber, dass er seine
B2-Framelength mittels ATS75=0x0800 auf vernuenftige Werte
einstellen soll, da er sonst NUR kompatibel zu anderen ISDN
Blaster Karten ist. Er kann dann immer noch 16k Byte Frames
empfangen.
Wenn es beim Senden von Daten oft zu CRC Fehlern kommnt, kann
das daran liegen, dass die Gegenseite nur mit Windowsize 1
empfaengt. In diesem Fall kann man bei 'cFos' mit ATS26=1 zur
Not auch auf eine Windowsize 1 "herunter-schalten". Die
meisten Karten koennen aber eine Windowsize von 2.
Wir empfehlen deshalb eine Windowsize von 2 ! Oder sollte sich
im FidoNet die Steinzeit-DFUE durchsetzen ?
Zum gegenwaertigen Zeitpunkt laeuft ISDN im FidoNet alles
andere als toll. Das liegt unter anderem daran, dass man sich
bisher nicht auf einen ISDN B2- und B3-Protokoll Standard
geeinigt hat. Denn wenn zwei Karten mit unterschiedlichen
Protokoll-Parametern miteinander connecten, kommt es frueher
oder spaeter zu Uebertragungsproblemen und
Verbindungsabbruechen.
Man muss sich also frueher oder spaeter darauf einigen was
genau denn das ISDNC Flag in der Nodelist bedeuten soll.
Hierzu unser Vorschlag (und cFos' default Einstellung) :
B2-Protokoll : X.75 (logisch :-) )
B2-Framelength : 2048 (s. obige Erlaeuterung)
Link-Address A : 3 (CAPI default)
Link-Address B : 1 (CAPI default)
Modulo Mode : 8 (CAPI default)
Windowsize : 2 (s. obige Erlaeuterung)
mehr braucht bei 2048 auch zuviel
Speicher
B3-Protokoll : transparent, also keines.
Wir meinen, dass die Chancen fuer einen guten Transfer so am
hoechsten sind.
11. 'cFos' als Multiport Fossil :
Theoretisch kann 'cFos' bis zu 255 verschiedene Ports
unterstuetzen. Einen Rechner mit der dazugehoerigen Leistung und
dem entsprechenden ISDN Equipment (8
Primaermultiplex-Anschluesse :-) ) moechten wir aber erstmal
sehen. Diese 'cFos' Version ist so kompiliert, dass man bis zu
vier COM Ports aktivieren kann. Fuer jeden COM Port wird dann
beim Installieren Buffer- und Datenspeicher reserviert. Man kann
z.B. beim Aufruf -c0 und -c1 verwenden, um COM1 und COM2 zu
unterstuetzen.
Entsprechend gibt es dann zwei Modem-Emulatoren und man kann
gleichzeitig bei zwei verschieden Systemen anrufen oder von
einem angerufen werden und auf dem anderen Port einen RING
beantworten. Das setzt allerdings MultiPort-faehige Software
oder einen Multitasker voraus.
Im MultiPort-Betrieb hoeren z.Z. alle "Modems"/Ports auf RINGs
mit automatischen Ringdown vom ersten mit -c spezifizierten Port
zum naechsten. In einer spaeteren Version wird man aber fuer
alle Ports seperat EAZs einstellen koennen, die sich auch
ueberschneiden duerfen.
12. 'cFos' Channel Bundling (CCB):
Das Channel Bundling von 'cFos' wurde so designed, dass es
unabhaengig von den Herstellern des jeweiligen CAPIs ist. D.h.
jeder 'cFos' User kann mit jedem anderen 'cFos' User buendeln,
auch dann, wenn die Teilnehmer verschiedene ISDN Hardware haben.
'cFos' Channel Bundling (CCB) ist kein Protokoll, sondern eine
Betriebsart. Man kann also sowohl mit X.75 als auch mit V110
buendeln.
Voraussetzung fuer CCB ist, dass das vorhandene ISDN Equipment
mehrere B Kanaele gleichzeitig mit Dienst "Datenuebertragung"
betreiben kann. Dies ist z.B. bei TELES und AVM Karten (nicht
alte A1 Karten) der Fall, ebenso bei ELSA ab CAPI 1.43. Mit der
Stollmann Tina DS und Tina D (wohl aber mit Tina DD) ist dies
nicht moeglich, da einer der beiden B Kanaele hardwaremaessig
nur fuer den A/B Adapter zur Verfuegung steht.
Weitere Voraussetzung ist, dass cFos fuer mehrere Ports geladen
ist. Dies ist z.B. der Fall, wenn es im MultiPort Betrieb
geladen wurde, d.h. wenn mehrere Ports durch Verwendung von -c
Parametern aktiviert sind.
Soll 'cFos' aber nur einen Port unterstuetzen, kann man mit dem
Parameter -aX sogenannte Auxiliary Ports aktivieren. Diese
werden dann intern von 'cFos' benutzt, koennen aber von aussen,
d.h. durch INT 14 calls nicht angesprochen werden. Der Parameter
X gibt an, auf welchem Controller (ISDN Karte) der entsprechende
B Kanal betrieben werden soll. 'cFos' kann naemlich Channel
Bundling mit mehreren ISDN Karten gleichzeitig, sofern das CAPI
dies unterstuetzt.
Beispiele:
cfos i -c0 -c1 'cFos' ist im Multiport Mode geladen und
unterstuetzt die Ports COM1 und COM2. CCB
ist mit 2 Kanaelen moeglich
cfos i -c2 -a0 'cFos' unterstuetzt nur COM3. CCB ist aber
mit 2 Kanaelen moeglich, wobei sich der 2.
Kanal auf ISDN Karte 0 befindet. Dies wird
wohl der haeufigste Anwendungsfall sein.
cfos i -c0 -c2 -a1 'cFos' unterstuetzt COM1 und COM3. CCB ist
mit 2 oder 3 Kanaelen moeglich. Falls man
nur 2 Kanaelen zum Buendeln benutzt, wird
der "Hauptport" (COM1 oder COM3) und der
Auxiliary Port benutzt. Erst wenn 3 Kanaele
gebuendelt werden sollen, wird auch der
zweite Hauptport verwendet, sofern er zum
Zeitpunkt des Verbindungsaufbaus frei ist.
Dies ist leider etwas kompliziert geworden, aber ermoeglicht,
dass sich Channel Bundling und MultiPort Mode nicht gegenseitig
ausschliessen, sondern beliebig miteinander kombiniert werden
koennen
Grundsaetzlich waehlt 'cFos' neben dem Hauptport, von dem aus
das CCB gestartet wurde, bevorzugt Auxiliary Ports und erst wenn
keine mehr frei sind, weitere Hauptports. Wird auf einen
Hauptport zugegriffen, der aber gerade fuer einen anderen Port
gebuendelt ist, gibt der Modem Emulator auf alle Modem Kommandos
immer OK zurueck. Dies koennte z.B. der Fall sein, wenn unter
DesqView zwei Mailer Tasks laufen. Hat die eine gerade beide
Kanaele, gibt der Modem Emulator der anderen immer OK zurueck,
aber es wird kein Kommando ausgefuehrt. Auf diese Weise "weiss"
der Mailer aber, dass der Port "noch da ist".
Der aktive und passive Verbindungsaufbau beim CCB, insbesondere
die Wahl der Uebertragungsprotokolle unterscheiden sich nicht
vom Verbindungsaufbau mit einem Kanal. Auxiliary Ports haben das
gleiche PROFILE, wie der zughoerige Hauptport, mit Ausnahme des
Controller Bytes (S Register 40). Dieses wird durch den Wert des
-a Parameters bestimmt.
Das Modem Kommando AT&Bn bestimmt, wieviele Kanaele zum CCB
benutzt werden sollen. Mit ATD <nummer> werden die Kanaele
aufgebaut. Gibt man mit AT&Bn mehr Kanaele an, als 'cFos' beim
Aufruf eingerichtet hat, wird ERROR zurueckgegeben.
Gibt es hingegen genuegend Kanaele, die aber u.U anderweitig
verwendet wurden, wird CCB nur mit den verfuegbaren Kanaelen
durchgefuehrt. Gleiches gilt auch fuer eingehende Rufe. 'cFos'
prueft bei eingehenden Rufen, ob fuer eine Caller ID, samt
EAZ/SI/AddSI, schon eine Verbindung besteht und schaltet ggf. in
den Bundle Mode. Ruft man also ein 'cFos' zweimal gleichzeitig
mit gleicher Caller ID/EAZ an, wird CCB angenommen.
Voraussetzung fuer CCB ist deshalb, dass der Anrufer seine
Caller ID uebermittelt !
Hier ein Quicky zum testen:
CFOS i -a0 ; cfos mit defaults fuer COM1 + 1 Aux.Port laden
Terminal Software fuer COM1 starten
AT &F &B2 DS0 ; bei Zaphods BBS anrufen
Es sei noch bemerkt, dass es keine speziellen CONNECT Strings
fuer CCB gibt, da 'cFos' zum dem Zeitpunkt, zu dem es die
CONNECT Meldung ausgibt, noch keine Informationen ueber die
Anzahl der gebuendelten Kanaele hat. Dies wird insbesondere dann
schon gar nicht mehr der Fall sein, wenn, wie in Kapitel 17
angedeutet, lastabhaengiges Zu- und Abschalten einzelner Kanaele
implementiert sein wird.
13. Vertraeglichkeit von 'cFos' mit bestehender Software
Wir haben 'cFos' mit verschiedenen Applikationen und mit
verschiedener ISDN Hardware/Software getestet, wobei manche
Software Schwierigkeiten z.B. mit den hohen Baudraten hat (die
meisten Programm benutzen hierfuer einen signed int, dessen
Wertebereich allerdings bei 32767 sein oberes Ende erreicht.)
Laut der FOSSIL Spec. soll man die Lauffaehigkeit seines
FOSSIL's am besten dadurch testen, indem man existente Software
mit ihm testet.
Die "FOSSIL Unterstuetzung" mancher Terminalprogramme ist leider
nicht so berauschend, insbesondere wird teilweise PRO BYTE
einmal der Status abgefragt und dann (falls Daten vorhanden
sind) ein receive_char () Call benutzt, um das Character vom
FOSSIL abzuholen. Diese Art, mit dem FOSSIL umzugehen, erzeugt
pro Character mindestens 2 INT's und 2 IRET's (zusammen etwa
schon 2000 Takte bei einem 386'er mit QEMM oder EMM386), ganz
abgesehen von sonstigem Call-Overhead. Wir haben uns zwar Muehe
gegeben, selbst mit diesen Applikationen noch moeglichst schnell
Daten senden/empfangen zu koennen, jedoch ist es bei solcher
Behandlung des FOSSIL's auf langsamen Rechnern (speziell 386'ern
mit Memory-Manager) nicht moeglich, Daten mit gutem Durchsatz zu
uebertragen.
Hier sind ganz klar die Autoren der Terminalsoftware gefragt,
geeignetere Wege zu nutzen, das FOSSIL anzusteuern; das heisst
bei den meisten Programmen, Daten mit receive_block() und
transmit_block() in groesseren Blocken zu uebertragen, anstatt
jedes Byte einzeln.
Viele FOSSIL unterstuetzende Software muss eine Baudrate wissen,
mit der sie ueber den Seriellen Port (RS232) mit dem Modem reden
und auf den sie diesen Port 'locken'. Diese Baudrate ist fuer
die Kommunikation mit dem Modem sehr wichtig, bei unserer
Loesung (da ohne RS232 und ohne externes Modem) voellig egal. Um
auf der sicheren Seite zu sein, sollte man in solchen Feldern
eine Baudrate von 38400 oder 19200 eintragen.
FrontDoor
FidoNet-Mailer von Absolute Solutions (JoHo). Sowohl Mailer
wie auch Terminal-Programm gehen recht gut mit dem FOSSIL um,
weshalb man mit diesem Programm selbst bei langsamen Rechnern
(386DX mit 6MHz) und passiven Karten Uebertragungsraten von >
7300 cps erreichen kann. Auf schnelleren Rechnern ist FD eines
der besten Terminalprogramme, was wir finden konnten
(zumindest in Bezug auf Transferspeed).
Problem 1: FrontDoor besitzt ja die Eigenheit, nur "canned"
CONNECT strings erkennen zu koennen. In den Versionen < 2.11
gibt es da keinen fuer 64000 (wohl aber fuer 38400). Also muss
man einen anderen String dafuer verwenden, was zwar dazu
fuehrt, dass FD alle moeglichen Zeit-Dauern falsch berechnet,
aber immerhin laeuft.
Loesung 1: a) Du hast FD 2.20/c oder FD 2.11/nc, dann hast Du
dieses Problem nicht, b) Du benutzt andere CONNECT messages
fuer die "neuen" bps-Raten, oder c) Du hast kein FD >= 2.11,
dann sorgt ein 'ATS9.1=0' dafuer, dass immer "CONNECT 9600"
gemeldet wird, und deshalb kein Mailer sich beschwert. Damit
man aber immer schoen was in den Logfiles stehen hat, steht
dann noch das B2 Protokoll dahinter, also "CONNECT 9600/X75".
Das mag FD.
Problem 2: Die CallerID, die bei ISDN mitgeliefert wird. Wenn
es RINGed, dann steht bei 'cFos' dahinter die Nummer des
Anrufers und das findet FD meist gar nicht mehr gut, da bei
vielen Mailern der RING String auf "RING|" geaendert worden
ist, um ein "RINGING" zu akzeptieren.
Loesung 2: Leider kann man das "RING|" nicht in ein "RING "
aendern, sondern muss dem Modem-Emulator ein "ATS9.2=0" geben.
Damit wird das RINGING ausgeschaltet.
FrontDoor benoetigt etwa 250kb freien Speicher, sodass es
keinerlei Speicherprobleme geben solte (selbst unter DesQView
nicht).
InterMail
Wir selbst hatten leider nicht die Moeglichkeit InterMail zu
testen (da es PayWare ist), uns wurde jedoch gesagt, InterMail
verhalte sich nicht anders als FD, somit gilt das oben
geschriebene. (InterMail und FrontDoor entstammen den gleichen
Sourcen).
Ueber den Speicherbedarf von InterMail sind wir leider nicht
informiert (Mail?).
BinkleyTerm
Binkley benutzt (ebenso wie FD) sehr saubere und schnelle
Routinen, um das FOSSIL anzusteuern. Deshalb ist auch hier
selbst auf langsamen Rechnern fuer guten Datendurchsatz
gesorgt.
Problem: Binkley 2.50 (und 2.50 EE bis Beta D incl.) verwendet
(soweit wir wissen) fuer die Baudraten einen signed int. Das
fuehrt somit bei CONNECT 64000 oder hoeher zu Fehlern.
Loesung: Ein 'ATS9.1=1' gibt immer eine 9600 als Baudrate
zurueck und das klappt. Leider stimmen dann auch hier die
Timings nicht mehr.
Binkley (2.50 EE Beta D, non-overlay) benoetigt etwas ueber
300kb Speicher, somit sollte es auch hier keine Probleme
geben.
D'Bridge
D'Bridge (kurz: DB) ist ein Mailer von Chris Irwin aus dem
sonnigen Miami. Um 'cFos' mit DB zum laufen zu bekommen, kann
man im Menu unter CONFIG, Comm/Modem Setup in eine
Setup-Screen wechseln. Dort muss man in einer der DATA/1 ...
DATA/3 Zeilen in der Spalte 'MCF name' 'CFOS' eintragen.
Dann muss noch im DB system-directory eine Datei namens
CFOS.MCF (Modem Control File) liegen mit (mindestens)
folgendem Inhalt:
MCF CFOS ISDN-Karte + cFos
BAUD 64000
LOCKED
DELAY 0
INIT ATZ
OFFHOOK ATH1
ANSWER ATA
DIAL 300 ATD
DIAL 19200 ATD
DIAL 38400 ATD
DIAL 64000 ATD
TRANSLATE 9600 CONNECT 9600
TRANSLATE 38400 CONNECT 38400
TRANSLATE 64000 CONNECT 64000
Allerdings muss der CONNECT String mit einem der angegebenen
Strings voellig uebereinstimmen, sonst meldet DB eine Baudrate
von 0. Deshalb sollte man ein ATS9.4=0 setzen, damit das
'/X75...' hinter dem CONNECT nicht kommt. Wenn es eine andere
Loesung fuer DB gibt, bitten wir um einen Hinweis.
Das sollte alles sein. Es ist zu empfehlen, D'Bridge ab
Version 1.54 zu benutzten, da der Autor in dieser Version die
FOSSIL Aufrufe verbessert hat.
Yuppie!
Yuppie ist ein 3d-Pointprogramm von YEAsoft aus Aachen. Wir
hatten die Version 2.10 im Test. Es basiert in den
Uebertragungsroutinen auf Binkley und laeuft entsprechend gut.
Allerdings kann es kein 'CONNECT 64000' vertragen, weshalb ein
'ATS9.1=0' erforderlich ist, damit es bemerkt, dass eine
Anwahl erfolgreich war. Ansonsten benoetigt es recht viel
Speicher (es wurde in Clipper geschrieben), also moeglichst
CAPI und/oder FOSSIL in UMB's laden.
Portal of Power
Macht ueberhaupt keine Probleme. PoP macht beim Senden ab dem
2. File aus unbekanntem Grund eine kurze Pause. Dies liegt
nicht an 'cFos', ist aber auch kein Grund zur Besorgnis.
Man muss ein wenig aufpassen, dass man nicht automatisch einen
X00 laedt. Im Zweifel sollte die POP.BAT Datei aendern, um
dies zu verhindern.
CrossPoint
Ab der Version 2.14 des Fido-Mailers unterstuetzt XP auch
FOSSILs. Damit XP-FM ueberhaupt das FOSSIL unterstuetzt statt
seinen internen Routinen muss im XP Verzeichnis eine Datei mit
Namen "FOSSIL" existieren (Inhalt egal), am besten mit "ECHO >
FOSSIL" eine solche erzeugen.
Bis zur Version 2.10 von XP kann NUR der XP-FM (ab 2.14) zum
Pollen auf das FOSSIL zugreifen. Terminal-Modus laeuft NICHT!
XP erwartet, dass hinter jedem Communication Port auch ein
physikalisches Modem haengt und testet dies, indem es auf die
Ports mit eigener I/O zugreift. Um trotzdem mit XP ueber ISDN
pollen zu koennen, sollte man Mail von Hand packen und XP-FM
von Hand aufrufen.
Ab der Version 2.92 von XP ist die FOSSIL-Unterstuetzung jetzt
auch vollstaendig verfuegbar, z.B. im Terminalprogramm etc.
Dafuer muss einfach unter Kommunikation/Modem der Punkt
'FOSSIL' angeschaltet werden.
Maximus
Maximus ist ein BBS Program von Scott J. Dudley. Wir benutzen
es hier selber und hatten deshalb ausgiebig Zeit, sein
Verhalten zu testen.
Sowohl das WFC Interface von Maximus, wie der 'SpawnBBS' Start
macht auch mit 64000 Baud keine Probleme.
Menus und Textfiles werden characterweise ausgegeben, deshalb
ist hier nicht die volle ISDN Geschwindigkeit zu sehen, aber
das tut auch keinen grossen Abbruch. Bei einem Download
schickt Maximus Daten in 128 Byte Bloecken an das FOSSIL und
erreicht dadurch eine gute Transferspeed.
Leider benutzt Maximus beim Empfangen von Daten (Upload) nicht
die receive_block() Funktion des FOSSILs, sondern liesst Byte
fuer Byte mittels receive_char(). Dadurch entsteht ein
riesiger Overhead und die maximale Uebertragungsrate liegt bei
langsamen Rechnern unter der maximal moeglichen.
Wir haben zwar die receive_char() und get_status() Funktionen
in Assembler geschrieben und dadurch einen akzeptablen
Durchsatz erreicht. Allerdings wird Maximus beim Download
immer schneller sein, als beim Upload.
RemoteAccess
RemoteAccess ist eine BBS Software von Andrew Milner. Es lief
in unseren Tests gut und problemlos, erreicht
Datenuebertragungsraten von ueber 7300 cps und kann auch
selber ohne weiteres Anrufe entgegennehmen. Zumindest die
Version 2.00 sollte keine Probleme mit Baudraten von 38400
oder 64000 haben.
Leider kann RemoteAccess auch nur "canned" CONNECT Strings,
die in RACONFIG eingestellt werden muessen. In der Version
2.00 sind aber alle fuer ISDN benoetigten Strings vorhanden.
Lediglich den RING-String sollte man auf "RING " einstellen,
damit "RING CallerID" nicht mit "RINGING" verwechselt werden
kann.
PCBoard
Man benoetigt fuer die FOSSIL-Unterstuetzung eine PCBoard/M
Version. Damit laeuft 'cFos' dann aber ohne grosse Probleme,
allerdings muss mit 'ATS9.4=0' die CONNECT Meldung auf ein
'CONNECT <bps>' beschraenkt werden, da PCBoard die letzte Zahl
des CONNECT Strings als Baudrate benutzt. Weiterhin darf der
BIOS Emulator von 'cFos' bei PCBoard nicht auf force stehen
(also kein -e2).
Terminate
Terminate ist ein recht neues Terminalprogramm von Bo Bendtsen
aus Daenemark. Es hat Features "bis zum Abwinken", unter
anderem auch FOSSIL Support. Wir haben hier die Version 1.41
getestet.
Terminate benutzt leider die receive_char() und
transmit_char() Funktionen des FOSSIL's, somit kann der
Transfer auf langsamen Rechnern weit unter den maximalen 8000
cps liegen.
Terminate benoetigt zum Laufen seit der Version 1.3/1.4 etwa
300kb Speicher, Bo hat sich nochmal ins Zeug gelegt und den
Speicherbedarf drastisch gesenkt.
Zumindest ein Bug scheint in der Version 1.41 noch drin zu
sein, der dafuer sorgt, dass der INT 14 Vector vom Terminate
verdreht wird. Daher kann es sein, dass cFos z.b. beim
Deinstallieren meldet "cFos not found in memory".
TeleMate
TeleMate ist eines der bekanntesten Terminaprogramme auf dem
PC und verfuegt seit einigen Versionen auch FOSSIL Support.
Das Besondere an TeleMate ist vor allem sein internes
Multitasking, d.h. man kann gleichzeitig eine Datei downloaden
und einen Text editieren. Allerdings kostet dieses
Multitasking erheblich Transferspeed, wenn der Rechner nicht
schnell genug ist, soll heissen: ein 386DX-40 sollte es schon
sein, damit die Transferspeed angenehm ist.
Ansonsten hat TeleMate eine sehr elegante Art, das FOSSIL
anzusprechen, leider hat es aber lange Zeit mit TeleMate beim
Download CRC Fehler gegeben, die wir erst in der 'cFos'
Version 0.95 fixen konnten.
Der Speicherhunger von TeleMate allerdings ist mit ueber 430kb
recht hoch. Auch hier sollte man mit Treibern und residenten
Programmen sparen.
Wichtig: bei Konfigurieren des FOSSIL's in TeleMate darf die
Baudrate des Ports unter "Communication" auf maximal 38400
gestellt werden, sonst akzeptiert TeleMate das Setting
"FOSSIL" im "Terminal" Window nicht. Wenn das FOSSIL nicht
reagiert, erstmal checken, ob im "Terminal" Window
"Connection" noch auf "FOSSIL" steht.
XBTX
XBTX ist ein BTX Decoder von Juergen Buchmueller, und verfuegt
zumindest in der Version 1.50 uber FOSSIL Unterstuetzung. Da
man BTX auch ueber ISDN fahren kann und die Datex-J Ports der
Telekom ISDN-faehig sind, haben wir BTX Support in 'cFos'
eingebaut (ATB5).
XBTX sucht die Ports 0-7 nach einem FOSSIL ab. Allerdings
verwendet XBTX eine sehr unsanfte Methode, festzustellen, ob
ein FOSSIL geladen ist. Diese entstammt leider nicht der
FOSSIL Spec, sondern der Docu zu X00. Somit laueft ein FOSSIL
mit XBTX *NUR*, wenn dieses sich so meldet, wie X00 das tut.
Da das so nicht in der FOSSIL Spec vorgesehen ist, muss man
bei 'cFos' diese Option extra aktivieren; dazu dient der
Commandline-Switch '-jx'.
XBTX benoetigt zum erfolgreichen Laden ueber 490kb Speicher;
es ist daher hoechste Disziplin bei der Auswahl der TSR's
angesagt ;-).
DoorWay
Laeuft. Allerdings sollte man die Debug-Zeile auf dem
'ge-DoorWay-ten' Rechner ausschalten, da DoorWay sonst
dauerhaft die Aenderungen der Debug-Zeile uebertraegt (nicht
schlimm, aber stoerend).
DesQView
Wir haben 'cFos' mit DesQView als MultiPort-FOSSIL getestet;
dazu muss 'cFos' VOR DesQView mit mehreren -c Parametern (fuer
mehrere Ports) geladen werden, damit alle Tasks auf das
gleiche FOSSIL zugreifen koennen.
Wir haben unter DesQView von einem FrontDoor das andere
angerufen und hatten Transferraten >7500 cps (386DX-40).
MS-Windows
Soll 'cFos' mit MS-Windows benutzt werden, so MUSS es vor
Windows geladen werden. Einige Windows-Programme haben zwar
keine FOSSIL Unterstuetzung, koennen aber den INT 14h nutzen.
Mit diesen kann 'cFos' ebenfalls eingesetzt werden.
Waffle, HS/Link, CEXYZ 1.00
Auch mit dieser FOSSIL unterstuetzenden Software laeuft
'cFos'. Ebenso wurde die Co-Existenz von 'cFos' mit PAPI 0.16
und TALK getestet.
14. ISDN Hardware/Software
'cFos' setzt zwar auf dem CAPI, einer in Deutschland genormten
Schnittstelle auf, aber diese laesst leider einige Fragen offen,
sodass eine Applikation erst mit anderer Hardware getestet
werden muss. Hier unsere Erfahrungen (oder die anderer User zum
Thema ISDN Hardware):
TELES
'cFos' wurde an einer TELES.S0 ISDN Karte entwickelt und
getestet. Bei der Entwicklung stand und steht uns die Fa.
TELES GmbH, Berlin durch Support durch ihre CAPI-Entwickler
zur Verfuegung.
Wir betreiben unsere Mailbox (Zaphods BBS) mit 'cFos' an einer
TELES.S0 Karte und versuchen hier auch immer die neueste
Version des TELES CAPI's bereitzustellen (z. Zt. 2.4l).
'cFos' erkennt das CAPI von TELES und ermittelt, ob die Module
fuer V.110 oder Buendelprotokoll geladen sind. Entsprechend
wird die Benutzung von V.110 und TELES channel bundling und
damit ATB1..ATB3 erlaubt.
AVM
Sowohl auf der passiven AVM A1+ wie auf der aktiven AVM B1
laeuft 'cFos' gut. Probleme gibt es u.U. mit dem atypischen
Verhalten des X.75 der ISDN Blaster. Dazu gibt AVM aber
mittlerweile neue Treiber heraus (Version 2.07-10 oder
hoeher). Wenn man eine ISDN Blaster, die mit FOSSIL PCIF V5.78
laeuft, anrufen will, sollte man bei 'cFos' das -jp Flag (s.
auch Kapitel 3) verwenden.
Teilweise ist im AVM CAPI noch kein V.110 enthalten; wenn dies
der Fall ist, sollte bei einem Anwahlversuch nach einer
CONNECT-Meldung ein ERROR/B2 auftreten. Wenn das der Fall ist,
sollte eine neue Version der CAPI's von AVM Abhilfe schaffen.
Allerdings gibt es alte A1 Karten, fuer die es keinen V.110
Treiber gibt.
In unserer Mailbox kann man die neuesten Treiber fuer die AVM
A1 v2.0 (AVMA1V2.ZIP), A1+ (AVMA1PL.ZIP), B1 v1.4 (AVMB1.ZIP)
und TIC (AVMTIC.ZIP) downloaden.
CPV Stollmann
Auf den aktiven Karten Tina D und Tina DS laueft 'cFos' gut
und selbst auf langsamen Rechnern schoen schnell.
Das CAPI von Stollmann kann zwar z.Z. noch kein V.110, aber
das wird sich wohl demnaechst nach Auskunft von Stollmann
aendern.
In unserer Mailbox bieten wir die neuesten Treiber fuer diese
Karten an (TINACAPI.ZIP und TINAETSI.ZIP). Diese sollte man
unbedingt verwenden und auch, wie dort beschrieben, den Aufruf
TICAPI -b, um mit der ISDN Blaster keine Probleme beim
Verbindungsaufbau zu haben.
Es existiert eine COM-Port Emulation, die, wenn geladen,
leider verhindert, dass 'cFos' sich beim CAPI erfolgreich
registrieren kann. Wenn man 'cFos' benutzen moechte, darf
dieses Modul nicht geladen werden.
CPV Stollmann hat uns freundlicherweise eine TINA DS zu Test-
zwecken zur Verfuegung gestellt. 'cFos' sollte deshalb
problemlos mit ihr laufen.
{+} Mit der TINA D und Tina DS funktioniert das Channel Bundling
leider nicht (wohl aber mit der Tina DD), da der zweite
B-Kanal hardwaremaessig mit dem integrierten A/B Adapter
verbunden ist und dem CAPI nicht zur Verfuegung steht.
mbp SOLIS
Die SOLIS Karten der Firma mbp laufen mit 'cFos' gut, wenn man
folgendes beachtet:
In der Serviced EAZ Mask (Register 13 oder AT&L Kommando) darf
die EAZ 9 nicht gelistet sein. Sollte dies doch der Fall sein,
so nimmt die Karte keinerlei Rufe entgegen.
Bei Laden von 'cFos' muss der Switch -jr angegeben werden.
Die SOLIS hat eine Modem-Emulation, die auf verschiedene
COM-Ports eingestellt werden kann. Nach Aussagen von
Betreibern dieser Karte laeuft 'cFos' nur dann, wenn man die
Modem-Emulation auf einen anderen Port einstellt, als das
FOSSIL oder den COM-Port ganz ausschaltet.
Bitte auf jeden Fall die letzte verfuegbare CAPI Version
benutzen, da die alten Versionen Probleme machen.
ITK iX1
Das iX1 CAPI erlaubt nicht, mit einer Windowsize kleiner als 2
zu registrieren ('cFos' default ist 2). Ansonsten laeuft 'cFos'
gut.
ELSA MicroLink ISDN/PC, ISDN/PCC
ELSA stellte uns freundlicherweise ihre Microlink ISDN/PC
Einsteckkarte samt CAPI 1.43 zum Test.
'cFos' laeuft in dieser Konfiguration gut. Das ELSA CAPI ist
schoen klein und schnell, kann aber (noch) kein V110. Als
"Ausgleich" besitzt die ISDN/PC dafuer aber einen COM-Port mit
einem 16550.
{+} Ab CAPI 1.43 laeuft auch 'cFos' Channel Bundling problemlos.
Sedlbauer S0-Box
Die S0-Box isy ein externes Geraet, welches auf den
Printer-Port aufgesteckt wird. Alle Daten zwischen ISDN und
Rechner muessen ueber den Printer-Port ausgetauscht werden. Da
dieses "Nadeloehr" recht eng ist, unterstuetzt die S0-Box nur
einen Kanal und kann deshalb nicht mit dem 'cFos' Channel
Bundling benutzt werden.
Weiterhin unterstuetzt die S0-Box bisher nur Windowsize 7,
daher muss 'cFos' mit "cfos i -w7" geladen werden.
Wenn man das beachtet, laeuft die Box nach Angaben der
Entwickler mit 'cFos' ohne Probleme.
Andere:
Falls Probleme mit einer ISDN-Hardware auftreten, bitte zuerst
ueberpruefen, ob es nicht inzwischen neuere CAPI Treiber o. ae.
gibt und wenn ja, diese benutzen.
Wir moechten uns an dieser Stelle nochmal fuer die ausgespochen
gute Unterstuetzung und Zusammenarbeit mit den ISDN
entwickelnden Firmen bedanken, besonders bei TELES, AVM,
CPV-Stollmann und ELSA.
15. Verschiedenes :
- Disconnect Reasons, die 'cFos' an die Gegenseite meldet, sind:
0x00 : normal disconnect (auch 0x80)
0xbe : call rejected
0xbb : user busy
0xb9 : out of order
Die Reasons kommen dann bei der Gegenseit als 0x34?? Causes
an, je nach dem, ob sie von den Vermittlungsstellen
weitergegeben werden.
- Service Indicator (SI) ungleich 7
Waehlt man in S14 andere Services als "Datenuebertragung",
meldet 'cFos' bei eingehenden Rufen (wenn in der Service Mask
das entsprechende Bit gesetzt ist) "CONNECT VOICE" bei SI = 1
und selektiert als B2-Protokoll "bittransparent". Auf diese
Weise kann man "Telefonie" betreiben.
Ist SI <> 7 und SI <> 1 meldet 'cFos' z.Z. noch "CONNECT ?"
und selektiert X.75 als B2-Protokoll.
Beim aktiven Verbidungsaufbau kann man mit S16 selbst einen
Service Indicator bestimmen, genauso wie man mit S17, S20, S21
den Additional Service Indicator, sowie B2- und B3-Protokoll
waehlen kann.
- For further Study
Wer gerne etwas tiefer in die ISDN Materie einsteigen will,
der sei hier auf folgende Literatur (inclusive Programme)
verwiesen:
CAPI Dokumentation
COMMON-ISDN-API, Einheitliche Schnittstelle zwischen
Applikationsprogrammen und ISDN-Adaptern, Spezifikation,
Version 1.1, Profil A, Editorisches Datum: 07.09.90
z.B. bei Zaphods BBS als ISDNAPI.ZIP, 24k
1.TR.6 Dokumentation
Die 1.TR.6 Dokumentation ist bei folgender Adresse erhaeltlich:
DBP Telekom
FA Bad Kreuznach
Projekt Roland
Arbeitskreis CAPI/PCI
z. Hd. Herrn Kreuzer
Postfach 9100
W-6550 Bad Kreuznach
PAPI Source
PAPI ist ein ISDN Packetdriver fuer TCP/IP, der auf dem CAPI
aufsetzt. Ein gutes Lehrstueck.
z.B. bei Zaphods BBS als PAPI016.ZIP, 38k
Wessen Interesse durch das Lesen dieser Doc oder das Benutzen
unseres FOSSIL an den FOSSIL Specs geweckt worden ist, der
lese folgendes:
FSC-0015
DIE FOSSIL Doc von Rick Moore. Als FSC-0015.A?? in jeder
guten FIDO-Box erhaeltlich, 25k.
X00REF.DOC
Die Function Refence von Ray Gwinn fuer FOSSIL developer.
enthaelt einige gute und wichtige Kommentare.
z.B. bei Zaphods BBS als X00150.ZIP, 105k.
- Falls tatsaechlich jemand die "V.110 inband negatiation"
benutzen sollte bekommt eine CONNECT 9600 Meldung, da 'cFos'
nicht wissen kann, mit welcher Baudrate tatsaechlich connected
wurde.
16. CAPI Fehlermeldungen:
Im folgenden eine Auflistung der CAPI Fehlermeldungen des CAPI
Arbeitskreises, erweitert durch V.110 Fehlermeldungen, 1.TR.6
Causes und herstellereigene Fehlermeldungen:
0x1001: Error on API_REGISTER
0x1002: Illegal application-id
0x1003: Illegal message
0x1004: Illegal command or subcommand
0x1005: Queue is full
0x1006: Queue is empty
0x1007: Queue overflow
0x1008: Deinstall error
0x1009: Windows address error
0x2001: Illegal Controller
0x2002: Illegal PLCI
0x2003: Illegal NCCI
0x2004: Illegal type
0x3101: B-channel erroneous
0x3102: Infomask erroneous
0x3103: Serviced-EAZ-mask erroneous
0x3104: Serviced-SI-mask erroneous
0x3105: Illegal B2 protocol
0x3106: Illegal DLPD
0x3107: Illegal B3 protocol
0x3108: Illegal NCPD
0x3109: Illegal NCPI
0x310A: Illegal flags
0x3201: General controller error
0x3202: non-unique LISTEN_REQs
0x3203: function not supported
0x3204: PLCI inactive
0x3205: NCCI inactive
0x3206: B2 protocol not supported
0x3207: can't select B2 protocol now
0x3208: B3 protocol not supported
0x3209: can't select B3 protocol now
0x320A: illegal DLPD parameters
0x320B: illegal NCPD parameters
0x320C: illegal NCPI parameters
0x320D: data length not supported
0x3301: D channel layer 1 setup error
0x3302: D channel layer 2 setup error
0x3303: B channel layer 1 setup error
0x3304: B channel layer 2 setup error
0x3305: D channel layer 1 shutdown
0x3306: D channel layer 2 shutdown
0x3307: D channel layer 3 shutdown
0x3308: B channel layer 1 shutdown
0x3309: B channel layer 2 shutdown
0x330A: B channel layer 3 shutdown
0x330B: B channel layer 2 reestablished
0x330C: B channel layer 3 reestablished
0x3400: Normal disconnect
0x3483: Bearer service not implemented
0x348a: No channel available
0x34a0: Outgoing calls barred
0x34a1: User access busy
0x34a3: Nonexistent CUG
0x34b5: Destination not obtainable
0x34b8: Number changed
0x34b9: Out of order
0x34ba: No user responding
0x34bb: User busy
0x34bd: Incoming calls barred
0x34be: Call rejected
0x34d9: Network congestion
0x34da: Remote user initiated
0x34f0: Local procedure error
0x34f1: Remote procedure error
0x4001: Stollmann: too many applications
0x4002: Stollmann: block size too large
0x4003: Stollmann: error on init of message queue
0x4004: Stollmann: no PLCI cntl block available
0x40ff: Stollmann: function not allowed in current context
0x4101: Verlust der Frame-Synchronisation
0x4201: Stollmann: can't deinstall, not on top of int chain
0x4202: Stollmann: can't deinstall, application still active
17. Addressen, Autoren, Verfuegbarkeit :
- Lizenzbedingungen
Siehe hierzu unsere Lizenz in COPYING.CF.
- Autoren
Christoph Lueders Martin Winkler
Fidonet: 2:2402/330.1 2:2402/330.6
Internet: chris@rhein.de winkler@zaphod.rhein.de
Surface Mail: Reuterstr. 133 Dorotheenstr. 38
53113 Bonn 53111 Bonn
Germany Germany
Voice: +49-228-223359 +49-228-650389
Telefon-Anrufe:
Da wir seit neuerem wegen 'cFos' sehr viel Zeit am Telefon
damit verbringen, Fragen, die eigentlich in dieser
Dokumentation beantwortet sind, zu beantworten, haben wir
mittlerweile eine im FidoNet erhaeltliche elektronische Mail-
Conference ins Leben gerufen, in der die meisten Fragen
angesprochen werden koennen. Sie heisst CFOS_HELP. Ausserdem
kann eine Mail an den SYSOP von Zaphods BBS (ISDN 0228-
9111041, V32b 0228-262894) oft schneller weiterhelfen, als ein
Anruf.
Wir bitten um Verstaendnis, dass wir aus Kostengruenden nicht
zurueckrufen koennen.
Also: Bei Fragen zuerst DOCs und CFOS.FAQ lesen, dann Mail
schreiben.
Anrufen kann man aber gerne, wenn man ISDN Equipment benutzt,
das in dieser Dokumentation nicht aufgefuehrt ist.
Bei Problemen mit der Konfiguration von Software ist es u.U.
eine gute Idee, Kontakt mit den "Help-Sites" der entsprech-
enden Software aufzunehmen.
Mail/Bug-Reports:
Was uns immer interessiert, sind
- offensichtliche Bugs in 'cFos' oder der Dokumentation.
- Erfahrungsberichte mit uns noch unbekannter Software oder
ISDN Karten.
- Anregungen, was man noch in 'cFos' einbauen sollte.
- was man alles noch mit 'cFos' machen kann. Willkommen sind
z.B. Telefonnummern fuer DATEX-P <--> ISDN Gateways, etc...
Eine Mail an uns sollte auf Fall folgendes enthalten:
- den Namen und bei Bug Reports oder ISDN Karten, die nicht in
dieser Dokumentation aufgefuehrt sind, die Voicenummer,
damit wir im Bedarfsfalle kurzfristig zurueckrufen koennen.
- Versionsnummer von 'cFos'
- Verwendeter Rechner, Software und ISDN Karte mit Versions-
nummer des CAPI Treibers.
- Neue Versionen
Die neueste Version von 'cFos' ist immer in unserer eigenen
Box, Zaphods BBS in Bonn erhaeltlich. Allerdings geben wir uns
Muehe, die Archive moeglichst schnell moeglichst weit zu
verbreiten, dazu gehoeren FIDO Mailboxen, Internet Fileserver
und MAUS Boxen.
Telefonnumern und Adressen stehen auch in COPYING.CF.
In zukuenftigen Versionen planen wir
- Den Speicherbedarf von 'cFos' weiter zu reduzieren.
- Die ATIn displays uebersichtiger zu gestalten.
- Die +++ escape sequence zu unterstuetzen.
- AT&E Kommandos im MultiPort Betrieb fuer jeden Port seperat
einstellbar zu machen.
- Eine FOSSIL user appendage speziell fuer ISDN Zwecke z.B.
mit der Funktion "Get charging info" mit in 'cFos'
einzubauen.
- Ralf Brown's AMISL Alternate Multiplex Interrupt
Specification fuer residente Programme zu unterstuetzen.
{+} - Beim 'cFos' Channel Bundling fuer Highest Speed Transfers
unter Minimierung der Kosten lastabhaengiges Kanal Zu-
und Abschalten zu implementieren.
{+} - Zahlreiche Log Funktionen zur Auswertung der Telefon-Kosten,
eingegangener Rufe, etc. einzubauen.
18. Credits
Die Reihenfolge impliziert keine Wertung ;-)
Andreas Illg, Alexander Bell, Eberhard Mattes, Dietmar Friede,
Uwe Engelmann, Mirko Mucko, Scott J. Dudley, Robert Bergermann,
Jens Osterwohldt, Markus Kessler, Olaf Droege, Tobias Erichsen,
Jan Ceuleers, Kalle Braun, Roland Steinmeyer, Oliver von Bueren,
Rainer Schuetze.
19. End of Documentation; Thanx for using 'cFos'.
Practice random kindness and senseless acts of beauty!