Für Phoner ist die CAPI eine eine ganz normale Schnittstelle, die alles oder nichts sein kann. Phoner weiss also nicht, dass da ein Netzwerk darunter liegt.

Du solltest mal über Alternativen nachdenken, z.B. Stomper.

Ich kenne ja dein Umfeld nicht. Aber vielleicht hast du eh schon einen Linux-Server rumstehen, der eigentlich ISDN abhandelt. Dann solltest du mal einen Blick auf [url=http://www.asterisk.org]Asterisk[url] werfen. In diesem Fall kannst du Phoner im SIP-Modus verwenden.

Quote:
Die Frage war ein wenig irreführend.
Ich formulier Sie neu: 
Lässt sich Phoner gegenüber allgemeinen CAPI-Trägheiten tolerant gestalten?

Wenn also von einer beliebigen CAPI mal für einige Sekunden nichts kommt, hängt Phoner sich dann prinzipiell auf?

Ein Phoner-Neustart inkl. funktionsfähiger CAPI funktioniert ja, also steht die CAPI weiter unbeeiträchtigt zur Verfügung. 
Wäre es nicht besser, wenn Phoner solche Aussetzter auch selbst handhaben könnte, statt sie nur zu erleiden?

@Marcel

für mich sieht das eher so aus, als ob das W-LAN bzw. der W-LAN-Router "auf doof gesagt" ziemlich überrascht ist, dass eine Anfrage erhalten wird, die "geforwardet" werden muss (zum CAPI-Server). 

Ein "Wake-Up-W-LAN" wäre mir in dieser Form aber nicht bekannt

Ursachen können da viele sein:

a) Unter WinXP verhält sich die eingebaute W-LAN-Konnektivität etwas träge; nutzt man client-seitig die Software des W-LAN-Clients, kann dieses damit schon behoben werden.

b) Nächster Grund ist die Konfiguration die zwischen WAN-LAN- oder LAN-LAN und W-LAN steht. Nutzt man ausschliesslich W-LAN über einen W-LAN-Router, ist ein einziges Gerät für WAN-WLAN bzw. LAN-LAN / W-LAN zuständig. 

Baut man ein internes W-LAN auf, dass eine LAN-WAN- bzw. LAN-LAN-Konnektivität jedoch über einen statischen LAN-Router zur Verfügung stellen soll, kann der W-LAN-Router mehrere Funktionen haben: Als NAT-Bridge, als REPEATER (um eine W-LAN-Signalstelle auszuweiten, oder als einfacher Gateway im Sinne eines Switch), etc.

Der Gateway ist dann beim W-LAN immer der Router, der direkt mit dem WAN bzw. dem LAN-am-LAN verbunden ist. Das wäre auch der Punkt, an der irgendeine Anfrage "auf der Strecke" bleiben könnte (wenn es nicht am Computer liegt).

Rein intuitiv tippe ich - ohne die genaue Konfiguration bei Dir zu kennen - auf einen Konflikt zwischen W-LAN und WAN-LAN bzw. LAN-LAN(möglich: 2 DHCP-Server, DNS kann nicht abgefragt werden, Client-Seitig besteht keine persistente Verbindung zum Server oder so etwas in dieser Art).

KEN arbeitet meiner Meinung nach so, dass sowohl der Client als auch der Server regelmäßig und häufig Informationen miteinander austauschen (dass erkennt man mit den "NET"-Befehlen der Eingabeaufforderung) oder sich regelmäßig suchen. Das hat den gleichen Effekt, als ob man - bei einer bestehenden, jedoch nicht  persistenten Verbindung - ein frequentes "Ping" sendet: Die Verbindung bricht nicht ab, weil irgendein Ruhe-Modus erst garnicht in Gang gesetzt wird.

Andere Remote-CAPI's registrieren sich einmal beim CAPI-Server. Sowohl Client und Server glauben, ohne diese Anmeldung zu überprüfen, das jeweils beide erreichbar sind, und wundern sich, wenn die persistente Verbindung zwischen Client und Server zwischenzeitlich abgebrochen ist (wenn man beispielsweise den Computer ausschaltet, ohne dass die Client-CAPI sich abmeldet). Das passierte mir mit Stomper ständig: Mein Client-Rechner hat 'nen Blue-Screen, und der Server zeigte mir den Stomper-Client weiterhin an, was bei zwischenzeitlich erfolgten Anrufen dazu führte, dass auch der Server einen Blue-Screen bekam. 

Der Name "Stomper" ist da meiner Erfahrung nach echt Programm... 

Grüße vom Kai

Die CAPI ansich ist komplett asynchron definiert. Man sendet also einen Befehl und kehrt unmittelbar zurück. Etwaige Antworten kommen dann später - man wartet nicht explizit darauf. Deshalb braucht Phoner da keinerlei Änderungen vorzunehmen...

Das Problem wird innerhalb der Remote-CAPI vorliegen. Wegen der Stabilitätsprobleme habe ich den CAPIProxy auch wieder entfernt. 
Probier bitte eine alternative Remote-CAPI aus. Stomper habe ich deshalb erwähnt, da die Einzelplatzlösung kostenlos ist.

Quote:
Aha. Jetzt verstehe ich, warum Phoner mit Reichweitenprobblemen im W-LAN auch prinzipiell keine Probleme hat, denn wenn über die Remote-CAPI die Daten unregelmäßig ankommen, kommen sie eben nur etwas später, man hört dann eben nur einige Aussetzer, was aber immer noch regelkonform ist, weil asynchron.


Seit v1.73 gibt es eine Veränderung in Verhalten:

Das freeze.log v1.73 ist sehr kurz

7C91EB8F: ntdll.dll - KiFastSystemCallRet
7C80244C: kernel32.dll - Sleep
10001A23: capi2032.dll -  

Aber bei mir hat die CAPI einen anderen Namen:

DLLName="C:\Programme\Phoner v1.66\capi20proxy.dll" 

Und wenn ich vergesse Phoner zu beenden, den Rechner in den Ruhezustand versetze, und ohne Netzwerkanbindung wieder starte, wird das freeze.log 1.73 noch kürzer

004799DB: phoner.exe - TControl.WndProc
00AF79BC:  -  

Bei v1.72 war das 'Einfrieren' beim Beenden nahezu 100-prozentig reproduzierbar, das tritt bei v1.73 deutlich seltener auf.
Hat sich da was verändert?

Häufig wird plötzlich das Programmfenster völlig weiß, die Gesprächsverbindung bleibt aber einwandfrei bestehen. 
Nur bedient, und gesehen werden kann dann natürlich nichts mehr, der Sanduhr-Cursor verweilt dann im Programmfenster.
Zum Beenden des Gesprächs hilft dann nur noch der Abschuss über den Taskmanager.

In diesem Fall gibt es dann bereits während des Gesprächs so ein freeze.log

7C91EB8F: ntdll.dll - KiFastSystemCallRet
10001A23: capi2032.dll -  

oder so eins

7C91EB8F: ntdll.dll - KiFastSystemCallRet
7C80244C: kernel32.dll - Sleep
10001A23: capi2032.dll -  

 
Wie gesagt, die Gesprächsverbindung selber besteht völlig unbeeinträchtigt weiter, als ob Phoner nur sein Fenster verloren hätte.

Der Test einer anderen Remote-CAPI begann mit ziemlichen Schwierigkeiten, da Phoner plötzlich nicht mehr auf mich hören wollte.

Quote:
Sowas aber auch, da hätt' ich aber auch eher drauf kommen können, dass der Eintrag nicht automatisch beim Start vom Phoner interpretiert wird, sondern nach jedem Phoner-Start erst noch einen Klick auf "OK" unter "Optionen/Kommunikation" erfordert. 
Da hab ich wohl mal wieder den Wald vor lauter Bäumen nicht gesehen.


PS: 
Die 1.70beta möchte übrigens auch nach jedem Start gedrückt werden.  
Wie nachlässig von mir, sowas so lange zu übersehen ...

Quote:
Ich hatte ja gehofft, dass ein wenig Herumgewedel mit dem Zaunpfahl reiche würde, aber ich kann auch Holzhammer:

Quote:
Ich hab die Sache erst mal abgebrochen, als ich feststellte, dass Phoner den Key "DLLName" nicht mehr interpretierte. 
Insbesonders deshalb, da es einst funktionierte - so dachte ich jedenfalls - und auch die 1.70beta, die das mal konnte - Hab ich selbst benutzt - und die ich noch vorrätig habe, diesen Key plötzlich auch nicht mehr kennen wollte. 

Dies so offensichtlich Unmögliche bedurfte einer aufwendigen Analyse.

Hier nun das überraschende Ergebnis:
Phoner interpretiert diesen Key niemals beim Start.
Phoner interpretiert seit v1.70beta den Key "DLLName" ausschließlich nach Betätigung des OK-Buttons im Geräte-Dialog unter Optionen/Kommunikation und schaltet erst danach auf die in der phoner.ini festgelegte CAPI um. 
Bei v1.73 werden auch erst dann die entsprechenden Keys in der sipper.ini aktualisiert.

Korrigierst Du das bitte?

PS:
Wenn die capi2032.dll im system32-Verzeichnis zufällig der capi20proxy ist, bleib im Umschaltmonent auf die andere CAPI der Phoner ebenfalls hängen.

7C91EB8F: ntdll.dll - KiFastSystemCallRet
7C80244C: kernel32.dll - Sleep
10001A23: capi2032.dll -  

Ich hätte nicht gedacht, dass das Freigeben einer .dll ein so gefährlicher Vorgang ist, dem man auf Gedeih und Verderb ausgeliefert ist.

PPS:
Großen Dank, dass dies hier doch schon jetzt und nicht wie angedroht, erst "irgendwann" geht.
Quote: