Page Index Toggle Pages: [1] 2 3  Send TopicPrint
Very Hot Topic (More than 25 Replies) Phoner friert an Remote-Capi über W-Lan ein (Read 20878 times)
Marcel
Full Member
***
Offline



Posts: 114
Joined: 27. Mar 2005
Gender: Male
Phoner friert an Remote-Capi über W-Lan ein
22. May 2005 at 15:15
Print Post  
Phoner bleibt hängen und zeigt dann "Phoner (CAPI: AVM-GmbH) (Keine Rückmeldung)" im Titel an.
Die Menüzeile wird wird weiß, gelegentlich wird auch das gesamte Programmfenster weiß.
Das Ganze geschieht, ...
-innerhalb von zwei Minutern nach Gesprächsbeginn,
-fast immer beim Beenden von Phoner
... aber nur wenn der Rechner über den W-LAN-AP 802.11b am CapiProxy auf 192.168.0.1 hängt.
Im W-LAN
Code
Select All
C:\>ping 192.168.0.1

Ping wird ausgeführt für 192.168.0.1 mit 32 Bytes Daten:

Zeitüberschreitung der Anforderung.
Antwort von 192.168.0.1: Bytes=32 Zeit=10ms TTL=128
Antwort von 192.168.0.1: Bytes=32 Zeit=6ms TTL=128
Antwort von 192.168.0.1: Bytes=32 Zeit=2ms TTL=128 

Wie man sieht, ist der erste Zugriff deutlich verzögert. Ich habe den Verdacht, das dieser Umstand (CAPI antwortet mehrere Sekunden lang nicht) Phoner jedesmal aus der Bahn wirft. 

Ich muss dann den Prozess über den Taskmanager beenden und Phoner neu starten was aber auch nur wenige Sekunden hilft. 

Erst wenn ich den Laptop wieder fest verkabel funktioniert alles wieder.  Scheint irgendwie mit den Zeiten zusammenzuhängen.
Im LAN
Code
Select All
C:\>ping 192.168.0.1

Ping wird ausgeführt für 192.168.0.1 mit 32 Bytes Daten:

Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=128 



Lässt sich Phoner gegenüber netzwerkbedingten Remote-CAPI-Trägheiten toleranter gestalten?
  

Quote:
Der Hörer, nicht der Sprecher, bestimmt die Bedeutung einer Aussage.
Heinz von Foerster in seinem Buch
Back to top
 
IP Logged
 
Phoner Admin
YaBB Administrator
*****
Offline



Posts: 11389
Location: Germany
Joined: 12. Oct 2003
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #1 - 22. May 2005 at 17:07
Print Post  
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.
  
Back to top
WWW  
IP Logged
 
Suppenkasper
God Member
*****
Offline


Phoner-Support

Posts: 1536
Location: Aachen
Joined: 29. Mar 2005
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #2 - 22. May 2005 at 17:16
Print Post  
@Marcel

Es ist zwar keine Standard-Lösung, und eigentlich auch ein wenig mammutös, doch mit KEN! von AVM als Remote-CAPI habe ich sowohl zu Hause als auch in der Firma ausschliesslich positive Erfahrungen gemacht. KEN! läuft auch im W-LAN ohne Verzögerung und überhaupt stabil.

Stomper dagegen hat bereits früher immer mal wieder einen Blue-Screen verursacht, und ein STOMPER-System verhältlich sich - bildlich gesprochen - meiner Meinung nach wie zäher Pudding. STOMPER-Clients finden nicht immer den Stomper-Server, auch wenn man die Server-IP eingibt, und wenn die Remote-CAPI mit dem CAPI-Server verbunden ist, "friert" der Server während eines Telefonates schon einmal gerne ein.
  
Back to top
IP Logged
 
Marcel
Full Member
***
Offline



Posts: 114
Joined: 27. Mar 2005
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #3 - 22. May 2005 at 18:41
Print Post  
Quote:
Lässt sich Phoner gegenüber netzwerkbedingten Remote-CAPI-Trägheiten toleranter gestalten?
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?
  

Quote:
Der Hörer, nicht der Sprecher, bestimmt die Bedeutung einer Aussage.
Heinz von Foerster in seinem Buch
Back to top
 
IP Logged
 
Marcel
Full Member
***
Offline



Posts: 114
Joined: 27. Mar 2005
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #4 - 22. May 2005 at 18:55
Print Post  
@ Suppenkasper_1970

Fällt Dir zur oben gezeigten Zeitüberschreitung irgendeine Lösung ein?
 
Warum hätte Phoner bei KEN kein Problem mit mehreren Sekunden Ruhe im W-LAN? 
Ich hab den Eindruck, das W-LAN schläft gelegentlich und braucht dann einige Sekunden zum Aufwachen.

PS: Wenn ich parallel zum Phoner einen 'ping 192.168.0.1 -t' zum Server laufen lasse, treten die Abstürze deutlich seltener auf.
« Last Edit: 22. May 2005 at 20:02 by Marcel »  

Quote:
Der Hörer, nicht der Sprecher, bestimmt die Bedeutung einer Aussage.
Heinz von Foerster in seinem Buch
Back to top
 
IP Logged
 
Suppenkasper
God Member
*****
Offline


Phoner-Support

Posts: 1536
Location: Aachen
Joined: 29. Mar 2005
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #5 - 22. May 2005 at 20:08
Print Post  
@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 Smiley

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...  Wink

Grüße vom Kai
  
Back to top
IP Logged
 
Marcel
Full Member
***
Offline



Posts: 114
Joined: 27. Mar 2005
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #6 - 22. May 2005 at 22:40
Print Post  
Ich habe hier den denkbar einfachsten Versuchsaufbau.

Einen Accesspoint LinksysWAP54G der z.Zt. fest auf 11b beschränkt ist, hängt direkt am Switch im gleichen LAN wie auch der Server mit dem CapiProxy.

Der Laptop ist ein Toshiba Tecra S1 mit vorinstalliertem Windows XP inkl. allen Treibern.
Die W-LAN Hardware unterliegt den damaligen Centrino-typischen Einschränkungen und ist nicht upgradefähig.

Noch eine Beobachtung:
Wenn ich bei bestehendem Gespräch und Dauerping mit dem Laptop die Reichweiten des W-LAN austeste stürzt Phoner nie ab, es kommt maximal zu kurzen Aussetzern im Gespräch.
  

Quote:
Der Hörer, nicht der Sprecher, bestimmt die Bedeutung einer Aussage.
Heinz von Foerster in seinem Buch
Back to top
 
IP Logged
 
Phoner Admin
YaBB Administrator
*****
Offline



Posts: 11389
Location: Germany
Joined: 12. Oct 2003
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #7 - 23. May 2005 at 08:59
Print Post  
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.
  
Back to top
WWW  
IP Logged
 
Suppenkasper
God Member
*****
Offline


Phoner-Support

Posts: 1536
Location: Aachen
Joined: 29. Mar 2005
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #8 - 23. May 2005 at 08:59
Print Post  
Quote:
Wenn ich bei bestehendem Gespräch und Dauerping mit dem Laptop die Reichweiten des W-LAN austeste stürzt Phoner nie ab, es kommt maximal zu kurzen Aussetzern im Gespräch.


Das Problem liegt wohl leider an der Stelle zwischen Switch und W-LAN-Router; Deine Beschreibungen deuten darauf hin, dass die Verbindung zum W-LAN nicht persistent ist, sondern nur, wenn Du das W-LAN "beschäftigst", aufgebaut wird, und danach besteht, wenn Du ständig eine Signalbrücke zwischen Deinem Rechner und Deinem Server aufbaust.

Auch "ping -l" stellt hier keine persistente Verbindung her, sondern imitiert eher eine "fast ständige" Verbindung: Ich empfehle deshalb, einmal mit KEN! zu testen (siehe Beschreibung oben). Ich vermute, dass die ständige Interaktion zwischen KEN!-Server und KEN!-Client auf Deinem Laptop das W-LAN "am laufen" hält.

Auch ist KEN! die denkbar professionellste CAPI-Proxy-Lösung im Verhältnis zum Preis; das nächstgrößere wäre von TobitSoft und kostete einige hundert Euro.

Grüße vom Kai
  
Back to top
IP Logged
 
Marcel
Full Member
***
Offline



Posts: 114
Joined: 27. Mar 2005
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #9 - 26. May 2005 at 05:37
Print Post  
Quote:
Die CAPI ansich ist komplett asynchron definiert. Man sendet also einen Befehl und kehrt unmittelbar zurück.
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
Code
Select All
7C91EB8F: ntdll.dll - KiFastSystemCallRet
7C80244C: kernel32.dll - Sleep
10001A23: capi2032.dll -  



Aber bei mir hat die CAPI einen anderen Namen:
Code
Select All
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
Code
Select All
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
Code
Select All
7C91EB8F: ntdll.dll - KiFastSystemCallRet
10001A23: capi2032.dll -  

oder so eins
Code
Select All
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.
  

Quote:
Der Hörer, nicht der Sprecher, bestimmt die Bedeutung einer Aussage.
Heinz von Foerster in seinem Buch
Back to top
 
IP Logged
 
Phoner Admin
YaBB Administrator
*****
Offline



Posts: 11389
Location: Germany
Joined: 12. Oct 2003
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #10 - 31. May 2005 at 09:01
Print Post  
Phoner ist Multi-Threaded aufgebaut, weshalb es normal sein kann, dass die Audio-Verbindung weiterläuft, während etwas anderes blockiert ist.

Trotzdem noch einmal an dieser Stelle: Die Ursache liegt im CapiProxy. Benutze deshalb also mal eine der angesprochenen Alternativen.

Ich selbst habe meinen Rechner über WLAN zum Router gekoppelt und habe im SIP-Modus keine solchen Probleme, was die Verzögerungen angeht. Ich kann darüber problemlos telefonieren.
  
Back to top
WWW  
IP Logged
 
Marcel
Full Member
***
Offline



Posts: 114
Joined: 27. Mar 2005
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #11 - 02. Jun 2005 at 06:07
Print Post  
Der Test einer anderen Remote-CAPI begann mit ziemlichen Schwierigkeiten, da Phoner plötzlich nicht mehr auf mich hören wollte. Undecided

Quote:
Code
Select All
7C91EB8F: ntdll.dll - KiFastSystemCallRet
7C80244C: kernel32.dll - Sleep
10001A23: capi2032.dll -  



Aber bei mir hat die CAPI einen anderen Namen:
Code
Select All
DLLName="C:\Programme\Phoner v1.66\capi20proxy.dll" 

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. Wink


PS: 
Die 1.70beta möchte übrigens auch nach jedem Start gedrückt werden. Shocked 
Wie nachlässig von mir, sowas so lange zu übersehen ...
« Last Edit: 02. Jun 2005 at 19:23 by Marcel »  

Quote:
Der Hörer, nicht der Sprecher, bestimmt die Bedeutung einer Aussage.
Heinz von Foerster in seinem Buch
Back to top
 
IP Logged
 
Phoner Admin
YaBB Administrator
*****
Offline



Posts: 11389
Location: Germany
Joined: 12. Oct 2003
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #12 - 03. Jun 2005 at 08:48
Print Post  
Ist jetzt damit dein Problem beseitigt? Funktioniert diese andere Remote-CAPI besser? Bitte teile uns deine Erfahrungen mit.
  
Back to top
WWW  
IP Logged
 
Marcel
Full Member
***
Offline



Posts: 114
Joined: 27. Mar 2005
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #13 - 03. Jun 2005 at 18:43
Print Post  
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.
Ich hatte ja gehofft, dass ein wenig Herumgewedel mit dem Zaunpfahl reiche würde, aber ich kann auch Holzhammer:

Quote:
Ist jetzt damit dein Problem beseitigt? Funktioniert diese andere Remote-CAPI besser? Bitte teile uns deine Erfahrungen mit.
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. Shocked
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.
Code
Select All
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:
Ich wusste, dass das kommt  Wink
Irgendwann wird das schon noch gehen...
« Last Edit: 04. Jun 2005 at 20:48 by Marcel »  

Quote:
Der Hörer, nicht der Sprecher, bestimmt die Bedeutung einer Aussage.
Heinz von Foerster in seinem Buch
Back to top
 
IP Logged
 
Marcel
Full Member
***
Offline



Posts: 114
Joined: 27. Mar 2005
Gender: Male
Re: Phoner friert an Remote-Capi über W-Lan ein
Reply #14 - 03. Jun 2005 at 21:14
Print Post  
So, ich hatte jetzt mal ein wenig Zeit und habe mal ein längeres Gespräch mit Unterstützung der anderen Remote-CAPI geführt.

Immerhin eine Stunde lief es, danach hatte ich eine sehr kurze freeze.log.
Code
Select All
7C91EB8F: ntdll.dll - KiFastSystemCallRet
 



Ausführlicher:
Das Gespräch verstummte, die Zeitanzeigen liefen weiter, Phoner blieb bedienbar.
Der Versuch, das Gespräch zu beenden führte zum Anhalten der Zeitanzeigen und zur Unbedienbarkeit. Auch normales Beenden ging nicht mehr.

Mein Gesprächspartner berichtete ebenfalls vom fortbestehen der stummen Verbindung für eine Minute bis ich Phoner wegen Nichtreaktion "sofort beendete". 
« Last Edit: 04. Jun 2005 at 12:28 by Marcel »  

Quote:
Der Hörer, nicht der Sprecher, bestimmt die Bedeutung einer Aussage.
Heinz von Foerster in seinem Buch
Back to top
 
IP Logged
 
Page Index Toggle Pages: [1] 2 3 
Send TopicPrint