LANCAPI 3.11 laesst sich nicht mit TK-Konfig-Programm nutzen

telchef · Beitrag von **telchef** » 08 Feb 2006, 13:18

Hallo LANCAPI-Lovers!

Leider läßt sich die aktuelle LANCAPI (3.11 aus Paket 3.12) nicht für die TK-Anlagen-Konfigurationsprogramme von Siemens (Hicom)/T-Com (Octopus) nutzen.

Hier findet man das TK-Konfigurations-Programm von T-Com für einige Octopus-Anlagen: Octopus Kunden Manager.

Es sieht so aus, als ob das Programm per CAPI-Message die Rufnummer anwählt (CAPI_PUT_MESSAGE: CONNECT_REQ), aber anschließend gleich wieder eine neue Message zum Auflegen sendet (CAPI_PUT_MESSAGE: DISCONNECT_RESP), während bei Lösungen mit ISDN-Karte auf den Verbindungsaufbau gewartet wird (CAPI_GET_MESSAGE: CONNECT_CONF, in dem u.a. Negativbeispiel kommt das nicht vor).

Ich habe mal mit AVMs CAPIKTrc ein Log eines solchen fehlerhaften Versuchs der LANCAPI-Nutzung erstellt (ISDN-Tln. 506 ruft TK-Anlage 879):

Code: Alles auswählen

--------------------------------------------------------------------------------
CAPIkTrc CAPI 2.0 Kernel Trace Driver v2.0  Build Date 11:29:21 Jun 30 2003

(c) AVM Berlin
--------------------------------------------------------------------------------
Tracing CAPI device "CAPI201"

19:41:51.702 Tue, Feb 07 2006
=== Target Device Query ===
Manufacturer:          ELSA, Aachen (Germany)
Number of Controllers: 1

--- Controller Nr. 1 ---
Serial Number:              
CAPI Version:               2.0
Manufacturer Version:       3.11
Profile:
01 00 08 00 01 00 00 00 - 07 00 00 00 03 02 00 00   ................
07 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00   ................

Total Number of BChannels: 8
-------------------------------------------------

19:41:51.702 Tue, Feb 07 2006
--------------------------------------------------------------------------------
Start Tracing
Settings:
  CAPI functions: YES
  CAPI messages:  YES
  MaxDataB3Bytes: 32
  CAPI ManuMessages:   YES
  UserMode Appls: YES

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


19:42:55.584 Tue, Feb 07 2006
ApplName: N/A
CAPI_REGISTER            (MJ_DEVICE_CONTROL (UserMode, FileObj 817FEB68, Irp 81642A58))
    InputBufferLength:  8 (0x8)    OutputBufferLength: 0 (0x0)
  MessageBufferSize:    3072
  maxLogicalConnection: 1
  maxBDataBLocks:       30
  maxBDataLength:       530


19:42:55.594 Tue, Feb 07 2006
ApplName: N/A
COMPLETION CAPI_REGISTER (MJ_DEVICE_CONTROL (UserMode, FileObj 817FEB68, Irp 81642A58))
    0x0000 (0x00000000: STATUS_SUCCESS, Information: 0 (0x0))


19:42:55.594 Tue, Feb 07 2006
ApplName: N/A
CAPI_GET_PROFILE            (MJ_DEVICE_CONTROL (UserMode, FileObj 816B29D8, Irp 81642A58))
    InputBufferLength:  4 (0x4)    OutputBufferLength: 64 (0x40)
  ControllerNr: 0 (additional parameter)


19:42:55.594 Tue, Feb 07 2006
ApplName: N/A
COMPLETION CAPI_GET_PROFILE (MJ_DEVICE_CONTROL (UserMode, FileObj 816B29D8, Irp 81642A58))
    0x0000 (0x00000000: STATUS_SUCCESS, Information: 64 (0x40))
  Profile (64 Bytes):
01 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00   ................


19:42:55.594 Tue, Feb 07 2006
ApplName: N/A
CAPI_GET_PROFILE            (MJ_DEVICE_CONTROL (UserMode, FileObj 816B29D8, Irp 81642A58))
    InputBufferLength:  4 (0x4)    OutputBufferLength: 64 (0x40)
  ControllerNr: 1 (additional parameter)


19:42:55.594 Tue, Feb 07 2006
ApplName: N/A
COMPLETION CAPI_GET_PROFILE (MJ_DEVICE_CONTROL (UserMode, FileObj 816B29D8, Irp 81642A58))
    0x0000 (0x00000000: STATUS_SUCCESS, Information: 64 (0x40))
  Profile (64 Bytes):
01 00 08 00 01 00 00 00 - 07 00 00 00 03 02 00 00   ................
07 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00   ................


19:42:55.594 Tue, Feb 07 2006
ApplName: N/A
CAPI_PUT_MESSAGE            (MJ_WRITE (UserMode, FileObj 817FEB68, Irp 81642A58))
    WriteBufferLength: 32 (0x20)
CONNECT_REQ                   32 Byte  ApplID: 1   MsgNr: 1
  Controller/PLCI/NCCI            = 0x00000001
  CIPValue                        = 0x0002
  CalledPartyNumber               = <80>879
  CallingPartyNumber              = <00 80>506
  CalledPartySubaddress           = default
  CallingPartySubaddress          = default
  BProtocol                       = default
  BC                              = default
  LLC                             = default
  HLC                             = default
  AdditionalInfo                  = default


19:42:55.604 Tue, Feb 07 2006
ApplName: N/A
COMPLETION CAPI_PUT_MESSAGE (MJ_WRITE (UserMode, FileObj 817FEB68, Irp 81642A58))
    0x0000 (0x00000000: STATUS_SUCCESS, Information: 32 (0x20))


19:42:55.644 Tue, Feb 07 2006
ApplName: N/A
CAPI_PUT_MESSAGE            (MJ_WRITE (UserMode, FileObj 817FEB68, Irp 81642A58))
    WriteBufferLength: 12 (0xC)
DISCONNECT_RESP               12 Byte  ApplID: 1   MsgNr: 33073
  Controller/PLCI/NCCI            = 0x00000101


19:42:55.644 Tue, Feb 07 2006
ApplName: N/A
COMPLETION CAPI_PUT_MESSAGE (MJ_WRITE (UserMode, FileObj 817FEB68, Irp 81642A58))
    0x0000 (0x00000000: STATUS_SUCCESS, Information: 12 (0xC))


19:43:01.032 Tue, Feb 07 2006
ApplName: N/A
CAPI_RELEASE            (MJ_DEVICE_CONTROL (UserMode, FileObj 817FEB68, Irp 81642A58))
    InputBufferLength:  0 (0x0)    OutputBufferLength: 0 (0x0)


19:43:01.042 Tue, Feb 07 2006
ApplName: N/A
COMPLETION CAPI_RELEASE (MJ_DEVICE_CONTROL (UserMode, FileObj 817FEB68, Irp 81642A58))
    0x0000 (0x00000000: STATUS_SUCCESS, Information: 0 (0x0))

19:43:31.165 Tue, Feb 07 2006
--------------------------------------------------------------------------------
Stop Tracing
--------------------------------------------------------------------------------

Vielleicht erkennt ein Mr. LANCAPI ja hier, wo's hängt.

Ich vermutete schon "nicht unterstützte Protokolle", jedoch wundert's mich, warum das CAPI-nutzende TK-Programm dann erst eine Wählanforderung sendet - fragt es doch vorher eindeutig per CAPI_GET_PROFILE das Profil der LANCAPI ab,

Gruß, Harald

EDIT: Das TK-Anlagen-Konfigurationsprogramm kann man auch ohne Telefonanlage benutzen, der Fehler tritt ja schon vor einer echten Verbindungsherstellung auf. Also einfach in's Leere die Standardrufnummer 879 wählen, oder eine beliebige Nebenstelle der eigenen TK-Anlage (auch ohne Endgerät), oder irgendeine Gegenstelle, die z.B. Datenanrufe entgegennimmt.

Anmelden kann man sich an dem Programm mit Benutzernamen "office" und Kennwort "office". Für Test ohne Anlage sind aber auch hier beliebige Eingaben möglich.

Die eigne Nebenstelle (abgehende MSN) konfiguriert man über Menü 'Optionen' / 'Programmeinstellungen...' / 'Kommunikation': 'Eigene MSN (Capi2.0)'. ('Übernehmen' nicht vergessen)

Den (simulierten) Abruf von Konfig-Daten aus der (nicht vorhandenen TK-Anlage) startet man mit der Schaltfläche 'Übertragen' in der Symbolleiste (stilisiertes Notebook vor TK-Gehäuse).
Im dadurch öffnenden Dialogfenster löst die Schaltfläche 'Octopus -> PC' den Anrufversuch aus.

MoinMoin · Beitrag von **MoinMoin** » 09 Feb 2006, 12:18

Moin, moin!

Kommuniziert das Konfigurationsprogramm mit der CAPI über die capi2032.dll? Oder geht es direkt an die Treiberschnittstelle? Ich kann mir nur vorstellen, daß der über die Treiberschnittstelle zurückgelieferte Info-Wert auch dann ausgewertet wird, wenn ein STATUS_SUCCESS zurückgemeldet wird. In dem Fall ist die Info aber undefiniert (und wird von der LANCOM CAPI offenbar nicht auf 0 gesetzt).

Ciao, Georg

telchef · Beitrag von **telchef** » 09 Feb 2006, 15:04

Hallo Georg!

Danke für Dein Interesse!

Meinst Du mit "Treiberschnittstelle" jetzt, daß das TK-Konfig-Programm direkt z.B. über AVMs fpcibase.sys kommuniziert? Das halte ich für sehr unwahrscheinlich.

Sicherlich wird es auch nicht, wie z.B. AVMs CAPI-Port-Treiber, über eine Art Treiberzugriff mit der capi2032.dll sprechen (vielleicht meintest Du das), beschwören kann ich das natürlich nicht.

Auf einem System mit Eicon-ISDN-Hardware habe ich das Programm auch schon laufen sehen, ebenso läuft es über die aktuelle NETCAPI von AVM für die FRITZ!Boxen.

Ich gehe mal davon aus, daß das TK-Konfigurationsprogramm ganz normal wie jede Anwendung über die CAPI-2.0-Anwendungsschnittstelle arbeitet.

(Mein Mitschnitt ist ja auch von dem CAPIKTrace-Programm - auch auf erfolgreichen Systemen, und auf diesen sieht man dann den gesamten erfolgreichen Verbindungsaufbau.)

Gruß, Harald

MoinMoin · Beitrag von **MoinMoin** » 09 Feb 2006, 15:11

Moin, moin!

telchef hat geschrieben:Meinst Du mit "Treiberschnittstelle" jetzt, daß das TK-Konfig-Programm direkt z.B. über AVMs fpcibase.sys kommuniziert?

Ich meine die in der CAPI-Spec definierte IOCTL-Schnittstelle, um direkt mit dem CAPI-Interface zu kommunizieren. Das ist die selbe Schnittstelle, die die CAPI2032.dll auch benutzt.

telchef hat geschrieben:Ich gehe mal davon aus, daß das TK-Konfigurationsprogramm ganz normal wie jede Anwendung über die CAPI-2.0-Anwendungsschnittstelle arbeitet.

Dann verstehe ich die Probleme nicht. Um sicherzustellen, welche Schnittstelle das Programm benutzt, könntest du AVMs Debug-DLL (ftp://ftp.avm.de/develper/debugdll) zum Tracen benutzen.

Ciao, Georg

telchef · Beitrag von **telchef** » 09 Feb 2006, 16:22

Hallo Georg!

Danke für den Tip. War nun mal ein Anlaß, mich genauer mit dem "Treiberzugriff" zu beschäftigen.

"IOCTL" war schon ein guter Hinweis. (Nebenbei: hieß wohl bei Win95 "IOCTL", bei NT/XP nennen sie es "Device Driver Level", wovon Du ja auch schon quasi in Deiner ersten Antwort schriebst.)

Nebenfrage: Ist es die capi2032.dll, welche den "Device Driver Level"-Zugriff bereitstellt oder ist es der Kartentreiber (z.B. rcapi.sys bzw. fpcibase.sys)?

EDIT: --Beim nochmaligen Lesen Deiner vorigen Antwort habe ich es wohl nun besser verstanden (Du hattest meine Frage quasi schon beantwortet): capi2032.dll nutzt direkt den "darunterliegenden" Kartentreiber, Anwendungsprogramm-mit-DDL nutzt auch direkt den Kartentreiber, nicht die capi2032.dll. Richtig?--

Wie ich im Log per debugdll erkennen kann, ob eine Anwendung (auch) "Device Driver Level"-Zugriffe macht, ist mir nicht ganz klar. Vielleicht sieht man es ja dort auch gar nicht, da diese an der capi2032.dll vorbeigehen (s. Frage oben)?

Ich habe jedenfalls auch noch mal ein Log damit gemacht, und das sagt nahezu das gleiche (ein normales Auflegen "0x3490"):

Code: Alles auswählen

-------------------------------------------------------------------------------
CAPI2032 Debug DLL v1.3.6                                 09.02.2006 - 15:52:42
CAPI Version: 2.0         Manufacturer Version: 3.11
Manufacturer: ELSA, Aachen (Germany)    Serial Number: 
Number of installed controllers: 1
Number of B-channels supported by controller 1: 8
-------------------------------------------------------------------------------

CAPI_INSTALLED: TRUE     04:55:12:77

CAPI_REGISTER: 0x0000     04:55:12:77
MessageBufferSize 3072
maxLogicalConnection 1
maxBDataBlocks 30
maxBDataLen 530
ApplID 1

CAPI_GET_PROFILE: 0x0000     04:55:12:77
Controller 0
Profile:
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


CAPI_GET_PROFILE: 0x0000     04:55:12:77
Controller 1
Profile:
01 00 08 00 01 00 00 00 07 00 00 00 03 02 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


CONNECT_REQ                ID=001 #0x0001 LEN=0032     04:55:12:78
  Controller/PLCI/NCCI            = 0x1
  CIPValue                        = 0x2
  CalledPartyNumber               = <80>879
  CallingPartyNumber              = <00 80>506
  CalledPartySubaddress           = default
  CallingPartySubaddress          = default
  BProtocol                       = default
  BC                              = default
  LLC                             = default
  HLC                             = default
  AdditionalInfo                  = default

CONNECT_CONF               ID=001 #0x0001 LEN=0014     04:55:12:81
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

DISCONNECT_IND             ID=001 #0x8000 LEN=0014     04:55:12:82
  Controller/PLCI/NCCI            = 0x101
  Reason                          = 0x3490

DISCONNECT_RESP            ID=001 #0x8000 LEN=0012     04:55:12:82
  Controller/PLCI/NCCI            = 0x101

CAPI_RELEASE: 0x0000     04:55:14:94
ApplID 1

Gruß, Harald

eddia · Beitrag von **eddia** » 09 Feb 2006, 17:55

Hallo Harald,

Leider läßt sich die aktuelle LANCAPI (3.11 aus Paket 3.12) nicht für die TK-Anlagen-Konfigurationsprogramme von Siemens (Hicom)/T-Com (Octopus) nutzen.

ich vermute mal, dass es daran liegt:

http://www.lancom-forum.de/htopic,1621,capi.html

Die Hipath Manager können nur Capi 1.1.

Gruß

Mario

telchef · Beitrag von **telchef** » 09 Feb 2006, 21:02

Hallo Mario!

eddia hat geschrieben:ich vermute mal, dass es daran liegt:

http://www.lancom-forum.de/htopic,1621,capi.html

Die Hipath Manager können nur Capi 1.1.

Danke für Deine Idee!

Das war vielleicht vor 10 Jahren so. Ein aktueller Assistant/Manager nutzt eindeutig die capi2032.dll.
Auch schon zu erkennen an der 'Kommunikation'seinstellung für die eigene 'MSN (Capi2.0)' im Manager.

Bei den schwerfälligen Behördenschädeln bei Siemens/T-Com wäre Deine Vermutung aber auch nicht unwahrscheinlich.

Hier müssen wir aber eher die Schwerfälligkeit der Firma Lancom Systems bemängeln, befürchte ich, welche seit 2001/2002 nichts mehr an der CAPI gemacht hat - und welche auch die "Low-Capabilities" LANCAPI "verbrochen" hat. Heißt ja sogar noch ELSA.

Gruß, Harald

eddia · Beitrag von **eddia** » 09 Feb 2006, 21:38

Hallo Harald,

Das war vielleicht vor 10 Jahren so. Ein aktueller Assistant/Manager nutzt eindeutig die capi2032.dll.
Auch schon zu erkennen an der 'Kommunikation'seinstellung für die eigene 'MSN (Capi2.0)' im Manager.

Ja - das habe ich auch schon gesehen. Und ich habe eigentlich immer einen aktuellen Manager E am laufen - der Assistant ist ja schon etwas älter.

Ich bezweifel jedoch, dass Siemens das komplett auf Capi2.0 umgestellt hat. Wenn ich schon in der Hilfe zum Manager etwas zu einer capi.dll lese, weiss ich nicht, ob das nur ein Lapsus ist oder wirklich eine 1.1er Capi meint. Zudem meine ich mich zu erinnern, das mal mit einer Eicon Diva ausprobiert zu haben, bei der man expliziet die Unterstützung von Capi1.1 und 2.0 auswählen konnte...

Gruß

Mario

alf29 · Beitrag von **alf29** » 09 Feb 2006, 22:17

Moin,

Hier müssen wir aber eher die Schwerfälligkeit der Firma Lancom Systems bemängeln, befürchte ich, welche seit 2001/2002 nichts mehr an der CAPI gemacht hat - und welche auch die "Low-Capabilities" LANCAPI "verbrochen" hat. Heißt ja sogar noch ELSA.

Wenn sich an der LANcapi nichts tut, dann hat das nichts mit der Schwerfälligkeit von
LANCOM zu tun, sondern mit dem mangelnden Interesse seitens der Kunden -> kein
Anreiz, daran etwas ernsthaft zu tun. In den letzten 3,4 Jahren habe ich von keinem
Projekt gehört, für das in irgendeiner Weise die Funktion der LANcapi Voraussetzung
gewesen wäre. Es gibt sicher eine Menge Einzelkunden, die sie für Dinge wie Fax
einsetzen (die Steuerung einer HiPath-Anlage rechne ich persönlich eher in die
Rubrik 'karierte Maiglöckchen'), aber es lohnt eben nicht für mehr, als den jetzigen
Stand am Laufen zu halten. Eine Portierung auf XP/64 zum Beispiel wird mit der
jetzigen Menge von Kunden mit Sicherheit nicht passieren...

Gruß Alfred

suvuk · Beitrag von **suvuk** » 09 Feb 2006, 22:40

Hi!
Die Problematik, die telchef hier hat, beschränkt sich nicht nur auf die Octopus-Anlage sondern sieht bei Euracom und div. anderen Anlagen genauso aus. Ich denke, hier sind die TK-Hersteller gefragt. Sofern die Anlage PPP-Einwahl für die Konfig unterstützt, klappt es doch.

Gruß
Suvuk

Beitrag von **LoUiS** » 10 Feb 2006, 09:03

Haaaalt Protest

ich habe meine Euracom 182 noch gestern Abend mit der LANCAPI ausgelesen, konfiguriert und auch wieder zurueckgeschrieben.

Ciao
LoUiS

telchef · Beitrag von **telchef** » 10 Feb 2006, 12:47

Hallo Mario!

eddia hat geschrieben:Ich bezweifel jedoch, dass Siemens das komplett auf Capi2.0 umgestellt hat. Wenn ich schon in der Hilfe zum Manager etwas zu einer capi.dll lese, weiss ich nicht, ob das nur ein Lapsus ist oder wirklich eine 1.1er Capi meint.

Da könnte natürlich was dran sein.

Nimmt man die capi2032.dll weg, gibt's auch eine Fehlermeldung im 'Übertragung'sfenster, welche CAPI.DLL erwähnt.

(Professionelle Sowftware-Entwicklung ist eben doch was für kompetente Spezialisten und professionelles Management, was beides vermutlich bei SIEMENS auch nicht so häufig ist.
Vermutlich haben Praktikanten oder Werkstudenten den Manager in der Mache.
Die Bedienkonzepte sind ja auch schon seit Generationen erbärmlich.

Aber solange man "Techniker" mit viel Zeitverbrauch und externe mit viel Verdienst schulen kann, wird sich da auch nicht viel ändern.

Es wird höchstens schlimmer, wenn erst die SW-Entwicklung nach Osteuropa und Indien outgesourct wird und anschließend auch noch die HW-Entwicklung.)

(Ich erwarte in SIEMENS' Preisregionen einfach Besseres!)

Gruß, Harald

telchef · Beitrag von **telchef** » 10 Feb 2006, 13:01

Hallo Alfred!

alf29 hat geschrieben:Wenn sich an der LANcapi nichts tut, dann hat das nichts mit der Schwerfälligkeit von
LANCOM zu tun, sondern mit dem mangelnden Interesse seitens der Kunden -> kein
Anreiz, daran etwas ernsthaft zu tun. In den letzten 3,4 Jahren habe ich von keinem
Projekt gehört, für das in irgendeiner Weise die Funktion der LANcapi Voraussetzung
gewesen wäre. Es gibt sicher eine Menge Einzelkunden, die sie für Dinge wie Fax
einsetzen (die Steuerung einer HiPath-Anlage rechne ich persönlich eher in die
Rubrik 'karierte Maiglöckchen'), aber es lohnt eben nicht für mehr, als den jetzigen
Stand am Laufen zu halten. Eine Portierung auf XP/64 zum Beispiel wird mit der
jetzigen Menge von Kunden mit Sicherheit nicht passieren...

Nicht immer alles aud die Kunden schieben!

Für die LANCAPI wird sowieso niemand bezahlen.

Und daß Lancom-Systems was an der LANCAPI ändert wegen einem "Kundenprojekt" - da glaube ich eher an den Weihnachtsmann.

Die Protokollfähigkeiten der LANCAPI sind seit Jahren erbärmlich.

Die LANCAPI kann und muß als Abgrenzungsmerkmal zu Wettbewerbern einfach dabei und hervorragend sein. Lancom-Systems spielt ja nicht gerade in der Billig-Liga, da muß dann auch was geboten werden.

Wenn der Kunde gleichwertige Angebote (ohne taugliche Netzwerk-CAPI) bei Wetbewerbern bekommt, und das auch noch zu niedrigeren Preisen, dann wird er sich nach und nach von Lancom-Systems abwenden.
Und momentan gibt's ja auch noch mit AVMs NETCAPI für die FRITZ!Boxen bessere und niedrigpreisigere Angebote.

Auch, wenn Du die Anwendung einer TK-Konfigurationssoftware für zu exotisch hältst, will ich Dir die Folgen erklären:

LANCOM-Geräte werden i.d.R. von IT-Spezialisten/-Administratioren eingesetzt und ausgewählt, nicht von Home-Usern oder Fax-Anwendern. Wenn diese dann ihre Administration nicht erledigen können, werden sie sich mittelfristig, wenn nicht gar kurzfristig von Lancom-Systems abwenden.

Ein Premium-Hersteller muß Premium-Produkte liefern, sonst wird er zum Durchschnittshersteller.

Beliebter Autovergleich:
Ein Lieferwagen, dessen Hersteller über Generationen keine einfache Möglichkeit für den Einbau eines Radios liefert, wird im Wettbewerb Nachteile haben, es sei denn, er ist billiger als alle anderen.

Teurer und weniger Möglichkeiten, das geht nur bei Lifestyle-Produkten - und das sind LANCOMs nun wirklich nicht

Ich las mal folgenden guten Spruch:
"Fortschritt gibt es nur dort, wo jemand mehr tut, als unbedingt nötig."

Gruß, Harald

alf29 · Beitrag von **alf29** » 10 Feb 2006, 13:37

Moin,

Für die LANCAPI wird sowieso niemand bezahlen.

Tja, dann wird eben auch keine Arbeit reingesteckt -
so funktioniert eine Marktwirtschaft eben...

Und daß Lancom-Systems was an der LANCAPI ändert wegen einem "Kundenprojekt" - da glaube ich eher an den Weihnachtsmann.

Mit dem Glauben an irgendwelche mythologischen
Figuren hat das recht wenig zu tun.

Wenn das Auftragsvolumen groß genug ist und der
Auftrag ohne eine (erweiterte) LANcapi nicht vergeben
wird, dann wäre das durchaus denkbar. Man muß das
nur an dem zu erwartenden Arbeitsaufwand messen,
ob es sich für LANCOM rechnet.

Die LANCAPI kann und muß als Abgrenzungsmerkmal zu Wettbewerbern einfach dabei und hervorragend sein. Lancom-Systems spielt ja nicht gerade in der Billig-Liga, da muß dann auch was geboten werden.

Ich wiederhole: mir ist kein Projekt aus den letzten Jahren
bekannt, das gerade wegen der LANcapi für LANCOM
entschieden wurde oder wo LANCOM wegen Mängeln
in der LANcapi rausgeflogen wäre. Offensichtlich ist sie
also für den von LANCOM anvisierten Kundenkreis kein
wichtiges Feature. Für die anderen Kuden, die gerne
eine erweiterte LANcapi hätten, ist das bedauerlich, aber
die Entwicklungsresourcen sind nun mal endlich und die
steckt man dorthin, wo man den größten Profit bekommt.

Und momentan gibt's ja auch noch mit AVMs NETCAPI für die FRITZ!Boxen bessere und niedrigpreisigere Angebote.

AVM zielt mit der F-Box auf einen völlig anderen
Kundenkreis als LANCOM. Es ist daher durchaus möglich,
daß dort so eine Capi viel wichtiger ist - und
dementsprechend tut AVM dafür etwas. Wir werden mit
Sicherheit Dinge finden, wo ein LANCOM mehr kann
als eine F-Box, an den AVM aber wieder nichts tut, weil
sie den Heimanwender eben nicht interessieren.

Beliebter Autovergleich:
Ein Lieferwagen, dessen Hersteller über Generationen keine einfache Möglichkeit für den Einbau eines Radios liefert, wird im Wettbewerb Nachteile haben, es sei denn, er ist billiger als alle anderen.

Wenn es der überwiegenden Mehrheit an Lieferfirmen aber
egal ist, ob ihre Mitarbeiter während der Arbeit Radio
hören können oder nicht, und stattdessen auf andere
Eigenschaften Wert legen, die diese Lieferwagen sehr
gut erfüllen, dann ist das eben kein Nachteil. Bei PKWs
sähe ein fehlendes Radio mit Sicherheit anders aus. Paßt
schon sehr gut, dieser Vergleich

Ich las mal folgenden guten Spruch:
"Fortschritt gibt es nur dort, wo jemand mehr tut, als unbedingt nötig."

...aber Profit macht man damit nur, wenn man dort mehr tut,
wo's die Kunden auch honorieren...alles andere fällt
in die Rubriken Hobby und Liebhaberei.

Es tut mir für Dich leid, daß LANCOM nicht genau
Deine Wünsche erfüllen kann, aber es müssen irgendwo
Prioritäten gesetzt werden. Offensichtlich teilt eine
Mehrheit der von LANCOM angezielten Kundschaft nicht
Deine Meinung, daß sie eine bessere LANcapi (oder
überhaupt eine...) bräuchten - und genau daran orientiert
sich LANCOM, an den Wünschen einer Mehrheit der
Kunden. Wobei 'Mehrheit' hier leider nicht in Personen,
sondern in Auftragsvolumina zu messen ist.

Gruß Alfred

telchef · Beitrag von **telchef** » 10 Feb 2006, 13:41

LoUiS hat geschrieben:ich habe meine Euracom 182 noch gestern Abend mit der LANCAPI ausgelesen, konfiguriert und auch wieder zurueckgeschrieben.

Das muß ich (leider

) bestätigen. Soeben erfolgreich eine Euracom 182 mit dem Konfigurator 4D03 über LANCAPI 3.11(3.12) ausgelesen.

("leider", weil das darauf hindeutet, daß der Fehler wohl doch in der SIEMENS-Software steckt. Und die sind ja total unbeweglich - bzw. man wird niemals einen kompetenten Ansprechpartner erreichen, es sei denn, man winkt mit einem Projekt, wo SIEMENS ab 250.000 EUR GEWINN macht.)

Gruß, Harald