NETCAPI ! ...

Status
Für weitere Antworten geschlossen.
COMMON ISDN API Fehler

Ok, wenn das also auch ohne Modem geht, was mir ziemlich seltsam vorkommt, denn irgendwie muss ja die Verbindung zur Telefonleitung hergestellt werden (ich geh' da mal mit meiner Bauernlogik vor), wie bekomme ich dann den CAPI Treiber auf meinen Rechner bzw. auf meine Box? Bitte idiotensicher beschreiben! Die in der Anleitung beschriebene Vorgehensweise setzt soviel Grundwissen voraus, das muss man sich aber auch irgendwie erstmal erarbeiten. Wenn mir einer sagt wo, dann nerve ich nicht mehr mit Standardfragen...
Gruß Martin
 
Re: COMMON ISDN API Fehler

martinhilde schrieb:
wie bekomme ich dann den CAPI Treiber auf meinen Rechner bzw. auf meine Box? Bitte idiotensicher beschreiben!
1. LAN-Capi auf FritzBox aktivieren mit #96*3* (deaktivieren mit #96*2*)
2. Capi2032.dll besorgen von ftp://ftp.avm.de/develper/dtrace.fritz!box/windows/dtrace.zip (ist in der ZIP enthalten, die anderen dateien werden nicht benötigt) und in den Ordner C:\WINDOWS\system32 kopieren
3. ISDN-Faxsoftware starten, z.B. RVS Comm oder Fritz! (ftp://ftp.avm.de//programs/fritz!/deutsch/fritz!_up_030603.exe)

Über die Capi ist es auch möglich, mit entsprechenden ISDN-PPP-Treibern (z.B. die von RVS Comm) eine ISDN-Datenverbindung aufzubauen, quasi als Fall-Back-Lösung, wenn DSL mal tot sein sollte, oder als Direkt-Datenverbindung zu z.B. Druckereien. Die Capiport-Treiber von AVM sollen wohl nicht funktionieren, mit den ISDN-PPP-Modemtreibern von RVS habe ich aber erfolgreich eine Internetverbindung aufbauen können, incl. Download mit voller ISDN-Geschwindigkeit.

Maximilianus
 
Wo findet man den RVS Comm?

Und wie lösche ich am besten die AVM FRITZ!web PPP over ISDN Netzwerkverbindung, wurde in dem Thread schon mal erklärt, aber ich finde es nicht wieder.

Danke
 
klappt eigentlich auch ein fallback auf analog wenn das DSL ausfallen sollte?
 
Hallo Susanne,

Code:
C:\Programme\FRITZ!\Inf.exe -d

EDIT: Ich hatte RVS-COM bei einer Telekom ISDN Karte (Teledat o.ä.) dabei. Ist soweit ich weiß nicht kostenlos zu haben.

Gruß Sascha
 
@maximilianus: Ich habe aber gar kein ISDN, und ich habe gar keine Fritzbox 7050, und ich habe gar keine Fritz!Card.

Ich denke, das funktioniert alles ohne!

Wie kann ich die Firmware editieren, falls das nötig oder überhaupt sinnvoll ist, also wie stelle ich eine Telnet-Verbindung her? Finde nichts dazu, was mich weiterbringt und verstehe nur Bahnhof.

Gruß Martin

---------------------------------------------

Fritz!Box Fon WLAN, Firmware-Version 08.03.73
T-Net analog
Win2k
 
martinhilde schrieb:
@maximilianus: Ich habe aber gar kein ISDN, und ich habe gar keine Fritzbox 7050, und ich habe gar keine Fritz!Card.

Ich denke, das funktioniert alles ohne!

Wie kann ich die Firmware editieren, falls das nötig oder überhaupt sinnvoll ist, also wie stelle ich eine Telnet-Verbindung her? Finde nichts dazu, was mich weiterbringt und verstehe nur Bahnhof.

Gruß Martin

---------------------------------------------

Fritz!Box Fon WLAN, Firmware-Version 08.03.73
T-Net analog
Win2k
Also bevor für die Fritz!Box Fon WLAN noch nicht die neue Firmware 08.03.85 oder höher veröffentlicht ist, muss man wohl zu dem dtrace.zip von AVM greifen, erhältlich auf dem AVM-FTP-Server.

Eine Fritz!Card ist nicht notwendig. Lies Dir mal die ganzen Themen zu Netcapi und Fax mit Fritz!Box durch.

Da ich selber die 7050 habe, kann ich zu der kleineren Fritz!Box leider nicht viel Hilfestellung geben.

Maximilianus
 
Neue Fehlermeldung: ISDN-Kabel nicht verbunden

Weil jetzt der CAPI-Treiber installiert ist, nachdem ich endlich geschnallt hatte, dass man dtrace.zip einfach wie ein Firmware-update auf die Box spielen muss, muckt die Kiste jetzt rum, dass das Kabel nicht mit der ISDN-Leitung verbunden ist. Hab ja auch kein ISDN. Was ist zu tun?
Gruß Martin

-------------------

Fritz!Box Fon WLAN
T-Net analog
Win2k
 

Anhänge

  • journal.gif
    journal.gif
    13.1 KB · Aufrufe: 249
Ich habe vorhin mal die Demoversion von RVS Com Pro an einem Analog-Anschluß getestet, hatte aber kein Glück.

Die Fritzbox wählt den Provider an und macht dann das modemtypische Handshaking, was man auch daran erkennt, daß der Traffic zwischen Fritzbox und Computer auf einmal auf ca. 10-11 kB/s pro Richtung ansteigt. Bei den meisten der 4-5 von mir getesteten Providern kommt aber keine Verbindung zustande und die Anwahl wird abgebrochen, entweder mit "Fehler 678 (Keine Antwort)" oder sinngemäß "Passwort und Username stimmen nicht."

Einzig bei Freenet kam einmal eine Verbindung mit sagenhaften 12 kbit/s zustande. Da dann mein Rechner aufgrund einer anderen Anwendung abgestürzt ist, konnte ich aber nicht testen, ob z.B. ein Ping funktionierte. Ein anderes Mal gab es einen Connect, nach der offensichtlich erfolgreichen Verifizierung von Username/Passwort kam aber sinngemäß die Meldung "Protokoll stimmt nicht überein". Nach jeder dieser zwei Verbindungen lief die Netcapi nicht mehr. Ursache ist nach meinen Erkenntnissen, daß der IGD(UPnP?)-Dienst auf der Fritzbox nicht mehr funktioniert. Dasselbe Phänomen hatte ich nämlich schon mal, als ich den AVM IGD CTRL Service auf dem PC beendet hatte und ich mich wunderte, daß die Netcapi nicht mehr lief. Jedoch erst ein Reboot der Fritzbox erweckte in diesem Fall die Netcapi wieder zum Leben, ein Reboot des PC dagegen wie bei der Beendigung des AVM IGD CTRL Service auf dem PC nicht. Da hätte ich mir die halbe Stunde RVS Com neu installieren und zigmal PC rebooten auch sparen können...

Bei mir funktioniert es also nicht, auch wenn es einige hoffnungsvolle Momente gab. Vielleicht liegt es an meinem nicht gerade highendigen System, vielleicht an der Fritzbox, vielleicht daran, daß die Modem-Emulation über Analog schwieriger zu handhaben ist als über ISDN, vielleicht ist es auch eine Kombination aus allem.
 
@martinhilde,

lesen, lesen und das gelesene umsetzen ...... ist mit meiner Anleitung eine 5min Geschichte.... 4min lesen eine Minute das gelesene umsetzen.

Und ansonsten erstmal einwenig in die Allgemeine Marterie Fritzbox einlesen!
 
Noch eine Frage: Beim Telefonieren über Fritz!Fon gibt es ein Echo von fast einer Sekunde. Ist das normal, bzw. kann man da was machen?
Gruß Martin
 
martinhilde schrieb:
Noch eine Frage: Beim Telefonieren über Fritz!Fon gibt es ein Echo von fast einer Sekunde. Ist das normal, bzw. kann man da was machen?
Gruß Martin

Auch hier trifft ..........

lesen, lesen und das gelesene umsetzen! Allerdings nicht weiter in diesem Thread, da dein Echoproblem nix mit der Capi zu tun hat!
Ein Tip, gebe mal in die Suche Echo & Codecreihenfolge ein.
Ansonsten kann die Echoproblematik auch eine unendliche Geschichte sein. :shock:
 
Da er beim Telefonieren über NetCAPI wohl kaum per VoIP telefoniert (weil: geht nicht! ;-) ), ist das kein typisches Echo-Problem, wie es bei VoIP auftritt.

@Martin: Interessant wäre, ob Du über Headset oder per Lautsprecher und Mikrofon telefonierst. Ich denke, mit einem Headset sollte bei richtiger Konfiguration des Rechners kein Echo auftreten.


Ich darf hier schon mal ankündigen, dass spätestens bei 30 Seiten in diesem Thread Schluss ist. Er wird einfach zu lang und die Experimentierphase ist ja so langsam vorbei.

Ich schlage vor, bei neuen Problemen einen neuen Thread aufzumachen. Damit alle wissen, worum es geht, bitte "NetCAPI" oder "CAPIoverTCP" in den Titel des Threads mit aufnehmen.
 
dm41 schrieb:
Da er beim Telefonieren über NetCAPI wohl kaum per VoIP telefoniert (weil: geht nicht! ;-) ), ist das kein typisches Echo-Problem, wie es bei VoIP auftritt.

Hatte ich was anderes behauptet? :gruebel:
 
susanne schrieb:
Hatte ich was anderes behauptet? :gruebel:
Ja! :doktor:
susanne schrieb:
Ein Tip, gebe mal in die Suche Echo & Codecreihenfolge ein.
Damit wäre er unweigerlich bei den typischen Echo-Problemen gelandet, die aber nur beim Telefonieren über VoIP auftreten. Und die Codecreihenfolge hat auch nur etwas mit VoIP zu tun. ;-)
 
Die Verbindung zwischen ISDN-Karte (gleich welcher Form, also auch FBF) erfolgt immer paketweise. Diese Pakete können - je nach ISDN-Karte/Capi unterschiedliche Blockgröße haben. So ein Paket muß erst voll werden, bevor es auf die Reise geht - daher kommt es zu einer Verzögerung.
Je kleiner die Pakete, desto geringer die Verzögerung.

Etwas pauschal (es gibt natürlich immer Ausnahmen) kann man sagen:
PCI-ISDN-Karten: kleinste Blockgröße möglich
USB-ISDN-Adapter: mittlere Blockgröße typisch
Netzwerk-Capi: große Blockgröße

Bei Netzwerk-ISDN kommt der Transportweg im Netz mit der Paketgröße der Netzwerkpakete hinzu. Damit erreicht eine Netzwerkcapi eine mehrfache Laufzeit als ein USB-Adapter (und schon die sind z.B. für Call-Back-Software zu stark verzögernd).

Bei analogen Gegenstellen ist immer etwas Übersprechen zwischen senden und empfangen. Je nach Verzögerung kommt also das eigene Signal sehr schnell oder langsamer zurück. Bei sehr schneller Rückkehr merkt man es nicht, es ist wie in einem normalen Zimmer, wo die Wände ja auch den Schall zurückwerfen. Dauert es länger, bis das eigene Signal zurückkommt ist es wie in einem großen Raum - nennt man Hall. Naja und ganz lange Verzögerungen, wie bei Netcapi kaum zu vermeiden, sind dann Echo.

Das ganze hat zunächst nichts mit Codecs zu tun, bei VoIP kommt allerdings durch die Kompression (und damit notwendigerweise entsprechender Blockgröße, ein einzelnes Bit kann man schließlich nicht verkleinern) letztlich genau der gleiche Effekt zustande. Deshalb werden dort die Echoprobleme häufig in Zusammenhang mit dem Codec angesprochen, insofern hat Susanne recht, dort findet man alle Infos zum Thema Laufzeitproblematik.

Auch die Situation, daß Echo-Beseitigung am besten auf der Gegenseite funktioniert (wenn dort ein ISDN-Telefon steht, gibts kaum echo) oder sehr viel Rechenleistung/einenDSP erfordert (sozusagen "eigenes Signal merken, warten bis es zurückkommt und dann aus dem Signal rausrechnen) ist wie von Susanne angegeben unter den entsprechenden Stichpunkten erläutert.
 
Andre,
fast alles ok, nur der Anfang
PCI-ISDN-Karten: kleinste Blockgröße möglich
USB-ISDN-Adapter: mittlere Blockgröße typisch
Netzwerk-Capi: große Blockgröße
ist leider falsch. :wink:

es stimmt hingegen: die Zeit für den Transport kommt hinzu. Etwas pauschal (es gibt natürlich immer Ausnahmen) kann man sagen:
Bei PCI: sehr klein
bei USB: grösser
bei Netzwerk: am grössten
 
NN,
Was meinst Du, was die Transportzeiten maßgeblich bestimmt?

Die Zeit für den reinen Transport auf der Leitung kommt immer dazu - aber Stom lässt sich nur schlecht beschleunigen. Der elektrische Strom ist in einem 5m USB-Kabel nicht schneller als in einem 5m Netzwerkkabel. Die Daten fließen also gleich schnell, wenn sie denn mal unterwegs sind...

Das Blockgrößenproblem wird als Ursache häufig vergessen, dabei ist genau das der Grund, wenn es um die Einzelelemente geht, die zusammen die "Bruttotransportzeit" ergeben:
Bruttotransportzeit =
+Zeit zum Sammeln und Verpacken der Information (Verladevorgang)
+Zeit auf der Strecke (nur von der Kabellänge abhängig, ggf bei Glasfaser schneller)
+Zeit in Zwischenverteilstationen
+Zeit für das Auspacken

USB-Adapter haben i.d.R. nur mittlere bis große Blockgrößen, da kleine Blöcke zu viel "Überhang" produzieren würden.

Ein Block muß halt erst mit Informationen "vollaufen", bevor er auf die Reise gehen kann. Und deshalb sind die Blockgrößen bei den kurzen Kabellängen häufig stärker maßgebend als die reinen Wegtransportzeiten. Der Weg geht schnell. Das Verpacken dauert... Und je größer die Pakete, desto länger.

Man kann den Effekt der Blockgröße übrigens sehr einfach selber testen. Man nehme McDialer (call-back-Software) und eine PCI-Karte, die auch kleine Blockgrößen unterstützt. Dann probiere man einen Call-Back bei kleinen Blöcken, bei mittlerer Blockgröße und bei großen Blöcken... Bei kleinen Blöcken super Qualität, bei größeren Echo...

Wie gesagt, der Strom im Netzwerk und im USB-Kabel ist gleich schnell.
Die Verpakungsstationen sind es, die bremsen. Und das tun sie, weil sie paketweise übertragen - und eben Datenpakete bei Netzwerkübertragung deutlich größer sind.

Die im Netzwerk bekannte Signallaufzeit kommt als Summe aller Entpack- und Verpackvorgänge zustande. Jeder Switch muß ein Paket erst vollständig empfangen, bevor es weiterverteilt werden kann. Je größer die Pakete, desto länger dauert das. Es müssen ja Verwaltungsdaten in jedem Paket mit übertragen werden (wer bin ich, wohin will ich, wo gibts hier Tee?), so daß sich nur größere Pakete im Netz lohnen.

Das TCP/IP-Netz hat mehr Verwaltungsüberhang als ein USB-Bus der wiederum mehr Verwaltungsüberhang als ein PCI-Bus hat. Wenn man davon ausgeht, daß man sich nur einen gewissen Wasserkopf leisten will/kann, dürfen die Pakete auf dem PCI-Bus ruhig kleiner sein - im Netz eben nicht.

Und genau dadurch entstehen die Unterschiede in der Brutotransportzeit. Die Netto-weg-transportzeit - also die Zeit, die die Daten auf der eigentlichen Leitung verbringen - ist im Heimbereich ziemlich irrelevant.

Insofern war meine Aussage oben keineswegs falsch, sondern die Ursache, warum die (Brutto!-)Transportzeiten so unterschiedlich sind.
 
dm41 schrieb:
susanne schrieb:
Hatte ich was anderes behauptet? :gruebel:
Ja! :doktor:

Ach du meine Güte :shock: , hatte ich doch tatsächlich den Zusatz "Fritz!Fon" überlesen, oder besser gesagt, da ein "Box" dazugelesen. :shock:

Hatte doch wirklich gedacht, der User ist drauf nach dem Motto ... ein Problem gelöst, auf zum nächsten ... egal obs in den Thread passt!

Somit auch ein Sorry an Martin. :)
 
Status
Für weitere Antworten geschlossen.
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.