[chan-capi-users] Hints for respond to incoming calls

[Armin Schindler]

On Tue, 7 Apr 2009, Andreas Ruf wrote:
...
>> So my conclusion is that your libcapi20 (which is in charge of using and
>> showing these values) is buggy!!! It is not acting according to CAPI 2.0
>> standard.
> Cited: the manufacturer's (and developer of the libcapi20) answers to my (two) questions regarding the above
>
> -The struct GlobalConfiguration seems to be not implemented in your libcapi20?
> "...die Zusatzfunktionen, die sich die Linux-Enwickler ausgedacht haben, kannten in den ersten Versionen diese GlobalConfiguration nicht. Um nun auf der einen Seite diese Struktur unterstützen zu können ohne auf der anderen Seite alle älteren Programme kaputtzumachen, haben die eine Version 3 der Library gemacht, die den Parameter kennt und eine Version 2, die ihn nicht kennt. Das ist der Grund für die zwei libcapi20.so Varianten, die wir installieren (libcapi20.so.2 und libcapi20.so.3).
> Standardmässig werden Anwendungen unter Linux mit dem Parameter
> CAPI_LIBRARY_V2 übersetzt, dann verwenden Sie die libcapi20.so.2 und
> benutzen GlobalConfiguration nicht. Durch ein paar Modifikationen an der
> jeweiligen Anwendung lässt sich die libcapi20.so.3 verwenden..."
>
> -Could applications (like chan_capi) relying on the correct
> implementation of this struct be misbehaving, if struct is not
> implemented?
> "...Ihre zweite Frage lässt sich generisch nicht beantworten. Ein Blick
> in die chan_capi Sourcen (im Internet frei verfügbar) zeigt jedoch, dass
> die aktuelle Version die Linux-Funktionen gar nicht verwendet, sondern
> die CAPI Nachrichten selbst formatiert (wie es auch richtig ist).
> chan_capi kontrolliert die Erzeugung von CAPI Nachrichten also
> vollständig selbst und ist der Ansicht, dass eine leere
> GlobalConfiguration Struktur in Ordnung ist (stimmt auch)..."
>
>
> Does chan_capi compile against libcapi20.so.3?
> Do you have any suggestions how to remedy the above?

chan_capi can be compiled using own libcapi20 functions or linked against
another libcapi20. In your case, since the special capi interface of your
ISDN card requires a special libcapi20-from-vendor, chan_capi must be 
linked against this libcapi20, not using own libcapi20 functions.

It is true that chan_capi doesn't use the libcapi20 extended functions to
build the capi-messages (as replied by your vendor), but this doesn't 
matter at all!!! The CAPI interface of your card/driver which receives
the capi messages, must be able to parse it correctly. And this is just not
done!

chan_capi can be linked against older version of libcapi20, but not all 
features are possbile then. The new .3 should be used.

Also, in the reply the vendor claims about GlobalConfiguration not beeing 
existent in older libcapi20. Basically that's true. But because of the 
nature of the CAPI message, it is possible to omit this.
GlobalConfiguration is part of a sub-structure, but when length of that 
structure tells no more data, it is just not used.
So for this issue, there is no difference between libcapi20.so.2 and .3 !
Just the extended functions of libcapi20 (which are not used with chan_capi)
are different, what was the reason for having .2 -> .3.
The raw capi message handling/parsing/use was never changed in linux and
is according to CAPI 2.0 spec.
I don't know where the capi message parsing is done for your ISDN card. In 
either case (driver of libcapi20-vendor), there is a bug when parsing the
capi message. The vendor should read the CAPI spec.

Armin