Der nachfolgende Thread greift die Kommunikation eines Kunden mit der Ferrari Hotline auf. Der Kunde setzt den Flex als CTI-Client ein. Als TSP wird "Siemens Hipath Tapi 170" verwendet. Seit der Umstellung des Faxservers (inkl. Konfigurationsübernahme) auf einen anderen Rechner kann der Kunde in unregelmäßigen Abständen nicht mehr wählen. Der Flex-Client meldet:
Kunde:
Sehr geehrte Damen und Herren,
nach dem Update auf die Version 4.1.0 gibt es bei einem unserer Kunden Probleme mit der ftapicti-Komponente. Es sieht so aus, als würden die TAPI-Lines zwar gefunden, können aber aus irgendeinem Grund nicht verwendet werden. Wir haben Testweise die ftapicti.exe mit der alten funktionierenden Version ersetzt. Das führt dazu, dass es zwar funktioniert, aber nur sehr instabil (laut dem Kunden, müssen die OfficeMaster Dienste mehrfach am Tag neu gestartet werden).
Informationen vom Kunden
gesendet: 29.11.2011 09:19
""das OfficeMaster meldet schon wieder CTI-Fehler. Ist also ohne Funktion!"
gesendet: 30.11.2011 16:45
""das OfficeMaster verhält sich immer merkwürdiger:
Auf diesem Client ist die Version 1.4.6.0 installiert
Der Kunde startet mehrfach am Tag die Dienste neu
Es existiert ein Log der ftapicti mit Debug-Loglevel allerdings hat diese Datei 30MB.Hier ein Auszug:
Logauszug (ftapicti0.0):
(9952) 11/12/02 06:08:17 - INFO: send Status: 30 'please wait for further info, i'm doing my best to put you in my userlist'
(9952) 11/12/02 06:08:17 - DEBUG: Known slot found (00B343CC) for 12
(9952) 11/12/02 06:08:17 - INFO: DisplayStatusMsg(Using 9 of 2048 licensed Cti users,Verwende 9 von 2048 lizensierten CTI-Benutzer,Busy)
(9952) 11/12/02 06:08:17 - INFO: UpdateUserList(): users license allocated (needed:9 vs. available:2048).
(9952) 11/12/02 06:08:17 - DEBUG: UpdateUserList: got users '00B343CC' properties
(9952) 11/12/02 06:08:17 - WARNING: 12 (19) LinesInServiceCount: Line 'Max.Mustermann 12'out of service
(9952) 11/12/02 06:08:17 - WARNING: 12 LinesInServiceCount: no lines in service
(9952) 11/12/02 06:08:17 - WARNING: 12 (19) GetTapiLine: Line 'Max.Mustermann´ not in service
(9952) 11/12/02 06:08:17 - ERROR: 12 IsLineInService: GetTapiLine '(null)' failed
Ferrari:
Hallo,
Laut Logdateien wurde der Tapi am Donnerstag und Freitag nicht neugestartet.
Letzten Mittwoch war in den Logs zu sehen, dass mehrere Leitungen außer Betrieb (Out of Service) sind, die uns der TelephonyServiceProvider (TSP) zur Verfügung stellt. Laut Log ist dort eine Hipath im Einsatz. Was wird dort als TelephonyServiceProvider verwendet (Estos, Siemens)?
Letzten Dienstag wurde 3x ein Neustart durchgeführt, jedoch melden die Tapilines des TSP immer noch „OUT_OF_SERVICE“ . Das gleiche gilt auch für letzten Montag.
Wenn uns der TelephonyServiceProvider „Out_of_Service“ meldet, kann der Officemaster die Tapi-Leitung nicht dem Benutzer bereitstellen, weil es zu dem Zeitpunkt keine Leitung gibt bzw. diese uns als nicht betriebsbereit vom TSP gemeldet wird.
Was für eine Fehlermeldung bekommt der User im Fehlerfall genau gemeldet (am besten mal ein Screenshot machen)?
Welcher TelephonyServiceProvider wird dort auf dem Server (auf dem der ftapicti.exe-Prozess läuft) eingesetzt?
Betrifft es immer die gleichen Benutzer oder auch andere?
Warum bekommen wir in regelmäßigen Abständen vom TSP gemeldet, dass die Leitung nicht zur Verfügung steht?
Die „Out_of_service“-Meldung vom TSP erklären auch die Fehlermeldungen vom Kunden. Wenn der Officemaster keine Leitung vom TSP bereitgestellt bekommt, kann demzufolge auch bei dem User nichts signalisiert werden. Sobald der TSP die Leitung wieder als betriebsbereit meldet, wird es wieder signalisiert.
Kunde:
TelephonyServiceProvider: Siemens Tapi 170
Was für eine Fehlermeldung bekommt der User im Fehlerfall genau gemeldet
Das Problem betrifft immer wechselnde Benutzer.
Außerdem scheint es heute wenig oder keine Probleme gegeben zu haben.
Ferrari:
Die besten Erfahrungen haben wir bisher mit Estos als TSP für SIemens HiPath gemacht.
Die Meldung des Flexclients besagt genau das in den Logdateien beschriebene Fehlerbild -> Leitung Out_of_Service, die uns vom TSP gemeldet wird.
Wenn die Verbindung zwischen Telefonanlage und TSP-Rechner problemlos besteht, wird auch keine Meldung vom Flex-Client generiert und an den Benutzer weitergemeldet. Wenn aber der TSP eine Leitung zur TK-Anlage nicht aufbauen kann und uns mit der Meldung „Out_of_Service“ antwortet, wird diese natürlich 1:1 von uns an den Flex-Client weitergeleitet. Der Benutzer bekommt dann die von Ihm geschilderte Fehlermeldung.
Wir setzen an der Stelle auf die Standardschnittstelle TAPI auf, die vom TSP von Siemens bereitgestellt wird. Wenn uns dieser mitteilt, dass die Tapi-Leitung ein Problem hat, telen wir dies dem Benutzer mit, in Form der Fehlermeldung.
Kunde:
Ihre Erklärung kann ich nachvollziehen, verstehe aber nicht, warum die Probleme ausgerecht dann begonnen haben, als wir das Update auf die Version 4.1.0 durchgeführt haben. Unser Kunde hat die HiPath TAPI vom TK-Anlagen-Anbieter erworben und ich glaube kaum, dass ich ihn jetzt dazu bewegen kann zusätzlich die ESTOS-TAPI zu kaufen. Er wird mich dann fragen, warum das Ganze bis zum Update reibungslos funktioniert hat. Die „Out_of_Service“ Meldungen habe ich nach dem Update zum ersten Mal überhaupt gesehen.
Leider scheint es so zu sein, als wenn das Problem nur temporär auftreten würde. Über eine Woche gab es jetzt keine Schwierigkeiten, bis heute. Es genügt dann, die ftapicti-Komponente neu zu starten und ein paar Minuten zu warten, dann laufen die Lines wieder.
Ich wäre schon froh, wenn es uns gemeinsam gelingen würde, den Grund für dieses Verhalten zu finden.
...später...
Jetzt ist mir eben bei der Durchsicht der Logs (dazu hatte ich vor meinem Urlab leider keine Zeit mehr) noch etwas aufgefallen:
Offensichtlich haben die TAPI-Lines auch mit der Version 4.1.0 funktioniert, es hat nur eine Weile gedauert. Das ist nun leider genau bei dem Update aufgetreten und ich habe daraus den falschen Schluss gezogen, dass es an dem Update liegen muss. Zudem zeigt das Log, dass am gleichen Tag morgens um 5:55 Uhr die TAPI-Lines auch Out of Service waren und zu dem Zeitpunkt war die OfficeMaster Version noch die alte.
Ferrari:
wir haben in der Vergangenheit die „Out_Of_Service“-Meldung nur in Zusammenhang mit Verbindungsfehlern/Netzwerkabbrüchen zwischen TSP und TK-Anlage beobachten können.
Gleichzeitig haben wir in der Vergangenheit auch die Erfahrung gemacht, dass ESTOS als TSP besser mit Siemens TK-Anlagen funktioniert als der TSP von Siemens selber. (Zur Info: Estos bietet auch eine 45-tägige Testversion an.)
Leider bekommen wir an keiner Stelle vom TSP mitgeteilt, warum es zu dem Fehler „Out_of_Service“ kommt. Bisher konnte dies aber meist mit Verbindungsabbrüchen (TSP<->TK) in Zusammenhang gebracht werden.
Ich habe auch nochmal Rücksprache mit unserer Entwicklung gehalten, bei unserer Tapi-Komponente hat sich zwischen den Versionen 4.03 und 4.1 nichts geändert.
Kunde:
herzlichen Dank für die Rückmeldung. Mittlerweile habe ich die Rückmeldung erhalten, dass der TSP auf dem Server „CSTA-Link not established“ meldet. Das deutet für mich auch alles auf Verbindungsprobleme hin. Das kein Unterscheid zwischen den TAPI-Komponenten zwischen der 4.0.3 und der 4.1.0 besteht, beruhigt mich auch und ist auch anhand der Logs nachvollziehbar (der Fehler trat ja schließlich auch mit der 4.0.3 auf).
Jetzt habe ich noch eine Frage: Der Kunde ist der Meinung, dass das Problem in einem Zusammenhang mit dem Exchange-Server steht. Zur Erklärung: Die Exchange-Organisation wird derzeit von Exchange 2007 auf Exchange 2010 umgestellt, momentan laufen beide Server parallel. Auf dem 2007er sind aber keine Postfächer mehr, nur noch diverse Connectoren u.a. auch der UMS-Connector.
Jetzt hat der Kunde während meines Urlaubs auf dem Exchange 2007 alle Dienste deaktiviert („Weil da drauf ja nichts mehr läuft“), als ich das mitbekommen habe, habe ich freundlich darum gebeten die Dienste bitte wieder zu starten. Der Kunde meint, dass während die Dienste inaktiv waren, kein TAPI-Fehler aufgetreten ist. Ich halte das für Zufall, oder hat das msx2kgate etwas mit der Anbindung von ftapicti und dem TSP zu tun? Ich kann mir das nicht vorstellen.
Den UMS-Connector werde ich dennoch zeitnah auf dem Exchange 2010 umstellen.
Ferrari:
nein das können wir an der Stelle ausschließen. Der TSP arbeitet nicht mit dem Exchange-Connector zusammen. Die einzige Stelle an der TSP und MSX zusammenwirken ist die MMC-Administration bei den Benutzern. Wenn man die MSX-Benutzeradministration öffnet und sich dort die Tapi-Lines anzeigen lässt. Das ist dann allerdings eine Verbindung der MMC zu ftapicti, nicht MSX zu Tapi. Das können wir also an der Stelle ausschließen. Ich denke eher, dass es Zufall war, dass der TSP nicht abgestürzt ist, als der Ex2007 ausgeschaltet war.
Kunde:
Problem gelöst:
Es war tatsächlich Zufall. Nachdem nun klar war, dass nur die Verbindung zwischen TSP und TK-Anlage das Problem war, habe ich mir diese näher angeschaut. Dabei hat sich herausgestellt, dass die IP-Adresse der TK-Anlage nach einer Umkonfiguration nun innerhalb des DHCP-Bereichs lag. Die IP-Adresse der TK-Anlage wurde durch den DHCP-Server auch an einen Blackberry vergeben, so dass die Verbindung zum TSP immer dann ausfiel, wenn der betreffende Mitarbeiter im Hause war. Das es zwischenzeitlich funktionierte, lag schlichtweg daran, dass der Mitarbeiter im Urlaub war.
Es war also alles falscher Alarm. Wenn die Verbindung nicht genau im Moment des Updates ausgefallen wäre, hätte ich auch schon viel früher daran gedacht. Ich möchte mich sehr herzlich für Ihre Unterstützung bedanken, sie hat mir die richtigen Denkanstösse geliefert.
Kunde:
Sehr geehrte Damen und Herren,
nach dem Update auf die Version 4.1.0 gibt es bei einem unserer Kunden Probleme mit der ftapicti-Komponente. Es sieht so aus, als würden die TAPI-Lines zwar gefunden, können aber aus irgendeinem Grund nicht verwendet werden. Wir haben Testweise die ftapicti.exe mit der alten funktionierenden Version ersetzt. Das führt dazu, dass es zwar funktioniert, aber nur sehr instabil (laut dem Kunden, müssen die OfficeMaster Dienste mehrfach am Tag neu gestartet werden).
Informationen vom Kunden
gesendet: 29.11.2011 09:19
""das OfficeMaster meldet schon wieder CTI-Fehler. Ist also ohne Funktion!"
gesendet: 30.11.2011 16:45
""das OfficeMaster verhält sich immer merkwürdiger:
- fällt nach Lust und Laune mehrfach am Tag aus
- mal werden Anrufe angezeigt – mal nicht
- dann mal ohne Namen
- im Hauptfenster aktuallisieren sich die Anruflisten nicht
Auf diesem Client ist die Version 1.4.6.0 installiert
Der Kunde startet mehrfach am Tag die Dienste neu
Es existiert ein Log der ftapicti mit Debug-Loglevel allerdings hat diese Datei 30MB.Hier ein Auszug:
Logauszug (ftapicti0.0):
(9952) 11/12/02 06:08:17 - INFO: send Status: 30 'please wait for further info, i'm doing my best to put you in my userlist'
(9952) 11/12/02 06:08:17 - DEBUG: Known slot found (00B343CC) for 12
(9952) 11/12/02 06:08:17 - INFO: DisplayStatusMsg(Using 9 of 2048 licensed Cti users,Verwende 9 von 2048 lizensierten CTI-Benutzer,Busy)
(9952) 11/12/02 06:08:17 - INFO: UpdateUserList(): users license allocated (needed:9 vs. available:2048).
(9952) 11/12/02 06:08:17 - DEBUG: UpdateUserList: got users '00B343CC' properties
(9952) 11/12/02 06:08:17 - WARNING: 12 (19) LinesInServiceCount: Line 'Max.Mustermann 12'out of service
(9952) 11/12/02 06:08:17 - WARNING: 12 LinesInServiceCount: no lines in service
(9952) 11/12/02 06:08:17 - WARNING: 12 (19) GetTapiLine: Line 'Max.Mustermann´ not in service
(9952) 11/12/02 06:08:17 - ERROR: 12 IsLineInService: GetTapiLine '(null)' failed
Ferrari:
Hallo,
Laut Logdateien wurde der Tapi am Donnerstag und Freitag nicht neugestartet.
Letzten Mittwoch war in den Logs zu sehen, dass mehrere Leitungen außer Betrieb (Out of Service) sind, die uns der TelephonyServiceProvider (TSP) zur Verfügung stellt. Laut Log ist dort eine Hipath im Einsatz. Was wird dort als TelephonyServiceProvider verwendet (Estos, Siemens)?
Letzten Dienstag wurde 3x ein Neustart durchgeführt, jedoch melden die Tapilines des TSP immer noch „OUT_OF_SERVICE“ . Das gleiche gilt auch für letzten Montag.
Wenn uns der TelephonyServiceProvider „Out_of_Service“ meldet, kann der Officemaster die Tapi-Leitung nicht dem Benutzer bereitstellen, weil es zu dem Zeitpunkt keine Leitung gibt bzw. diese uns als nicht betriebsbereit vom TSP gemeldet wird.
Was für eine Fehlermeldung bekommt der User im Fehlerfall genau gemeldet (am besten mal ein Screenshot machen)?
Welcher TelephonyServiceProvider wird dort auf dem Server (auf dem der ftapicti.exe-Prozess läuft) eingesetzt?
Betrifft es immer die gleichen Benutzer oder auch andere?
Warum bekommen wir in regelmäßigen Abständen vom TSP gemeldet, dass die Leitung nicht zur Verfügung steht?
Die „Out_of_service“-Meldung vom TSP erklären auch die Fehlermeldungen vom Kunden. Wenn der Officemaster keine Leitung vom TSP bereitgestellt bekommt, kann demzufolge auch bei dem User nichts signalisiert werden. Sobald der TSP die Leitung wieder als betriebsbereit meldet, wird es wieder signalisiert.
Kunde:
TelephonyServiceProvider: Siemens Tapi 170
Was für eine Fehlermeldung bekommt der User im Fehlerfall genau gemeldet
Das Problem betrifft immer wechselnde Benutzer.
Außerdem scheint es heute wenig oder keine Probleme gegeben zu haben.
Ferrari:
Die besten Erfahrungen haben wir bisher mit Estos als TSP für SIemens HiPath gemacht.
Die Meldung des Flexclients besagt genau das in den Logdateien beschriebene Fehlerbild -> Leitung Out_of_Service, die uns vom TSP gemeldet wird.
Wenn die Verbindung zwischen Telefonanlage und TSP-Rechner problemlos besteht, wird auch keine Meldung vom Flex-Client generiert und an den Benutzer weitergemeldet. Wenn aber der TSP eine Leitung zur TK-Anlage nicht aufbauen kann und uns mit der Meldung „Out_of_Service“ antwortet, wird diese natürlich 1:1 von uns an den Flex-Client weitergeleitet. Der Benutzer bekommt dann die von Ihm geschilderte Fehlermeldung.
Wir setzen an der Stelle auf die Standardschnittstelle TAPI auf, die vom TSP von Siemens bereitgestellt wird. Wenn uns dieser mitteilt, dass die Tapi-Leitung ein Problem hat, telen wir dies dem Benutzer mit, in Form der Fehlermeldung.
Kunde:
Ihre Erklärung kann ich nachvollziehen, verstehe aber nicht, warum die Probleme ausgerecht dann begonnen haben, als wir das Update auf die Version 4.1.0 durchgeführt haben. Unser Kunde hat die HiPath TAPI vom TK-Anlagen-Anbieter erworben und ich glaube kaum, dass ich ihn jetzt dazu bewegen kann zusätzlich die ESTOS-TAPI zu kaufen. Er wird mich dann fragen, warum das Ganze bis zum Update reibungslos funktioniert hat. Die „Out_of_Service“ Meldungen habe ich nach dem Update zum ersten Mal überhaupt gesehen.
Leider scheint es so zu sein, als wenn das Problem nur temporär auftreten würde. Über eine Woche gab es jetzt keine Schwierigkeiten, bis heute. Es genügt dann, die ftapicti-Komponente neu zu starten und ein paar Minuten zu warten, dann laufen die Lines wieder.
Ich wäre schon froh, wenn es uns gemeinsam gelingen würde, den Grund für dieses Verhalten zu finden.
...später...
Jetzt ist mir eben bei der Durchsicht der Logs (dazu hatte ich vor meinem Urlab leider keine Zeit mehr) noch etwas aufgefallen:
Offensichtlich haben die TAPI-Lines auch mit der Version 4.1.0 funktioniert, es hat nur eine Weile gedauert. Das ist nun leider genau bei dem Update aufgetreten und ich habe daraus den falschen Schluss gezogen, dass es an dem Update liegen muss. Zudem zeigt das Log, dass am gleichen Tag morgens um 5:55 Uhr die TAPI-Lines auch Out of Service waren und zu dem Zeitpunkt war die OfficeMaster Version noch die alte.
Ferrari:
wir haben in der Vergangenheit die „Out_Of_Service“-Meldung nur in Zusammenhang mit Verbindungsfehlern/Netzwerkabbrüchen zwischen TSP und TK-Anlage beobachten können.
Gleichzeitig haben wir in der Vergangenheit auch die Erfahrung gemacht, dass ESTOS als TSP besser mit Siemens TK-Anlagen funktioniert als der TSP von Siemens selber. (Zur Info: Estos bietet auch eine 45-tägige Testversion an.)
Leider bekommen wir an keiner Stelle vom TSP mitgeteilt, warum es zu dem Fehler „Out_of_Service“ kommt. Bisher konnte dies aber meist mit Verbindungsabbrüchen (TSP<->TK) in Zusammenhang gebracht werden.
Ich habe auch nochmal Rücksprache mit unserer Entwicklung gehalten, bei unserer Tapi-Komponente hat sich zwischen den Versionen 4.03 und 4.1 nichts geändert.
Kunde:
herzlichen Dank für die Rückmeldung. Mittlerweile habe ich die Rückmeldung erhalten, dass der TSP auf dem Server „CSTA-Link not established“ meldet. Das deutet für mich auch alles auf Verbindungsprobleme hin. Das kein Unterscheid zwischen den TAPI-Komponenten zwischen der 4.0.3 und der 4.1.0 besteht, beruhigt mich auch und ist auch anhand der Logs nachvollziehbar (der Fehler trat ja schließlich auch mit der 4.0.3 auf).
Jetzt habe ich noch eine Frage: Der Kunde ist der Meinung, dass das Problem in einem Zusammenhang mit dem Exchange-Server steht. Zur Erklärung: Die Exchange-Organisation wird derzeit von Exchange 2007 auf Exchange 2010 umgestellt, momentan laufen beide Server parallel. Auf dem 2007er sind aber keine Postfächer mehr, nur noch diverse Connectoren u.a. auch der UMS-Connector.
Jetzt hat der Kunde während meines Urlaubs auf dem Exchange 2007 alle Dienste deaktiviert („Weil da drauf ja nichts mehr läuft“), als ich das mitbekommen habe, habe ich freundlich darum gebeten die Dienste bitte wieder zu starten. Der Kunde meint, dass während die Dienste inaktiv waren, kein TAPI-Fehler aufgetreten ist. Ich halte das für Zufall, oder hat das msx2kgate etwas mit der Anbindung von ftapicti und dem TSP zu tun? Ich kann mir das nicht vorstellen.
Den UMS-Connector werde ich dennoch zeitnah auf dem Exchange 2010 umstellen.
Ferrari:
nein das können wir an der Stelle ausschließen. Der TSP arbeitet nicht mit dem Exchange-Connector zusammen. Die einzige Stelle an der TSP und MSX zusammenwirken ist die MMC-Administration bei den Benutzern. Wenn man die MSX-Benutzeradministration öffnet und sich dort die Tapi-Lines anzeigen lässt. Das ist dann allerdings eine Verbindung der MMC zu ftapicti, nicht MSX zu Tapi. Das können wir also an der Stelle ausschließen. Ich denke eher, dass es Zufall war, dass der TSP nicht abgestürzt ist, als der Ex2007 ausgeschaltet war.
Kunde:
Problem gelöst:
Es war tatsächlich Zufall. Nachdem nun klar war, dass nur die Verbindung zwischen TSP und TK-Anlage das Problem war, habe ich mir diese näher angeschaut. Dabei hat sich herausgestellt, dass die IP-Adresse der TK-Anlage nach einer Umkonfiguration nun innerhalb des DHCP-Bereichs lag. Die IP-Adresse der TK-Anlage wurde durch den DHCP-Server auch an einen Blackberry vergeben, so dass die Verbindung zum TSP immer dann ausfiel, wenn der betreffende Mitarbeiter im Hause war. Das es zwischenzeitlich funktionierte, lag schlichtweg daran, dass der Mitarbeiter im Urlaub war.
Es war also alles falscher Alarm. Wenn die Verbindung nicht genau im Moment des Updates ausgefallen wäre, hätte ich auch schon viel früher daran gedacht. Ich möchte mich sehr herzlich für Ihre Unterstützung bedanken, sie hat mir die richtigen Denkanstösse geliefert.