Hallo Ihr,
ich bin der Entwickler von dem oben angesprochenen Programm "daCAPI". Auf der Suche wegen einem Problem mit der AVM NetCAPI, in Verbindung mit dem Controller 5, bin ich durch Zufall hier auf Eure Diskussion gestoßen. Die Aussagen von PeterPawn zu den D-Kanal-Messages unterschreibe ich blind. Allerdings trifft die Aussage mit dem Erkennen der Zuständigkeit nicht unbedingt auf Monitore zu, die auf CAPI2.0 aufsetzen. In der Regel registriert sich eine Anwendung beim CAPI und teilt der Schnittstelle mit für welche Dienstkennungen sie Informationen erhalten möchte (LISTEN_REQ/CIPMask). Ein direktes Tracen der D-Kanal-Messages, und das Erkennen von Zuständigkeiten erfolgt somit nicht wirklich. Das CAPI bereitet die Informationen auf und übermittelt nur Infos für die die Anwendung sich angemeldet hat.
Warum CapiDog am C5 komplett ruhig bleibt, kann ich leider auch nicht beantworten. Vermutlich stöbert es ein oder zwei Schichten tiefer und versucht selber den D-Kanal auszuwerten. Fakt ist, ich bekomme die Calls vom CAPI, was telchef ja auch gesehen hat.
Die Tatsache, dass daCAPI von einem Trunk-Prefix x# nur die Raute entfernt, liegt in der Tat daran, dass mir diese Eigenheit schlicht nicht bekannt war. Kleine Entwickler haben oft das Problem, dass die Testmöglichkeiten und die Palette an verfügbarer Hardware begrenzt ist. Wir sind quasi darauf angewiesen, dass sich ein User die Mühe macht und mal eine Mail schreibt. Aber dank Euch, wenn auch indirekt, weiss ich es nun und kann darauf künftig reagieren.
Wegen der Vollständigkeit... mein eigentliches Problem mit dem C5 war, dass daCAPI abgehende Gespräche verhindert hat, sowie es auf dem CAPI hing. Das NetCAPI von AVM reagiert etwas zickig, da ich ein falsches Bit bei der Initialisierung gesetzt hatte. Alle mir sonst bekannten CAPIs haben damit kein Problem, weshalb es auch lange unentdeckt blieb.
Viele Grüße, Lutz
ich bin der Entwickler von dem oben angesprochenen Programm "daCAPI". Auf der Suche wegen einem Problem mit der AVM NetCAPI, in Verbindung mit dem Controller 5, bin ich durch Zufall hier auf Eure Diskussion gestoßen. Die Aussagen von PeterPawn zu den D-Kanal-Messages unterschreibe ich blind. Allerdings trifft die Aussage mit dem Erkennen der Zuständigkeit nicht unbedingt auf Monitore zu, die auf CAPI2.0 aufsetzen. In der Regel registriert sich eine Anwendung beim CAPI und teilt der Schnittstelle mit für welche Dienstkennungen sie Informationen erhalten möchte (LISTEN_REQ/CIPMask). Ein direktes Tracen der D-Kanal-Messages, und das Erkennen von Zuständigkeiten erfolgt somit nicht wirklich. Das CAPI bereitet die Informationen auf und übermittelt nur Infos für die die Anwendung sich angemeldet hat.
Warum CapiDog am C5 komplett ruhig bleibt, kann ich leider auch nicht beantworten. Vermutlich stöbert es ein oder zwei Schichten tiefer und versucht selber den D-Kanal auszuwerten. Fakt ist, ich bekomme die Calls vom CAPI, was telchef ja auch gesehen hat.
Die Tatsache, dass daCAPI von einem Trunk-Prefix x# nur die Raute entfernt, liegt in der Tat daran, dass mir diese Eigenheit schlicht nicht bekannt war. Kleine Entwickler haben oft das Problem, dass die Testmöglichkeiten und die Palette an verfügbarer Hardware begrenzt ist. Wir sind quasi darauf angewiesen, dass sich ein User die Mühe macht und mal eine Mail schreibt. Aber dank Euch, wenn auch indirekt, weiss ich es nun und kann darauf künftig reagieren.
Wegen der Vollständigkeit... mein eigentliches Problem mit dem C5 war, dass daCAPI abgehende Gespräche verhindert hat, sowie es auf dem CAPI hing. Das NetCAPI von AVM reagiert etwas zickig, da ich ein falsches Bit bei der Initialisierung gesetzt hatte. Alle mir sonst bekannten CAPIs haben damit kein Problem, weshalb es auch lange unentdeckt blieb.
Viele Grüße, Lutz
