Die TAPI-Schnittstelle bietet auch die Variante, einen Wählvorgang asynchron (im Hintergrund) durchzuführen. Hinsichtlich dieser Funktionalität wurde die TAPI-Schnittstelle um eine neue Möglichkeit erweitert.
Einleitung
Mit der TAPI-Schnittstelle in CONZEPT 16 kann eine bestehende Anwendung leicht um Telefoniefunktionen erweitert werden. Die API bietet dabei sowohl Befehle zum Herstellen von Verbindungen, wie auch zur Überwachung von Leitungen zur Registrierung eingehender Anrufe. Darüber hinaus bietet die TAPI-Schnittstelle noch erweiterte Funktionen, wie z.B. Konferenzschaltungen und Weiterleitungen. Für eine Einführung in die TAPI-Schnittstelle empfehle ich dem interessierten Leser die Blog-Artikel TAPI Ereignisse und TAPI Monitoring.
TapiDial
Für die Durchführung eines Wählvorgangs bietet die TAPI-Schnittstelle den Befehl TapiDial()
. Neben der zu wählenden Telefonnummer kann hier auch eine zusätzliche Option übergeben werden. Wird diese nicht angegeben, wird auf die Herstellung der Verbindung mit dem Gesprächspartner gewartet. Durch die Angabe von _TapiAsyncDial
wird der Wählvorgang hingegen nur gestartet. Der Befehl kehrt also bereits zurück, während die Verbindung asynchron aufgebaut wird. Dies ermöglicht es dem Anrufer Ereignisse der TAPI-Schnittstelle zu überwachen und darauf zu reagieren.
TapiListen
Das Überwachen von Ereignissen geschieht durch den Befehl TapiListen()
. Daraus ergibt sich die Problematik, dass zum einen durch den Befehl TapiDial()
Ereignisse ausgelöst werden, die auch wiederum durch das Monitoring über TapiListen()
erfasst werden. Die Ereignisse werden somit doppelt ausgelöst: einmal für die ausgehende Leitung (TapiDial()
) und einmal für die überwachte Leitung (TapiListen()
). Da die Call-ID der durch TapiDial()
generierten Verbindung nicht bekannt ist, kann hier nicht unterschieden werden, welche Ereignisse sich auf die ausgehende bzw. auf die eingehende Leitung beziehen.
Sag mir wer du bist…
Das Problem kann ab der kommenden Version 5.7.07 durch eine weitere Option bei TapiDial()
gelöst werden. Mit der Angabe von _TapiReturnCallID
wird ein asynchroner Wählvorgang gestartet, wie dies bereits mit _TapiAsyncDial
möglich ist. Jedoch liefert TapiDial()
im erfolgreichen Fall die Call-ID des generierten Anrufs zurück.
// Asynchroner Wählvorgang mit Rückgabe der Call-ID.
gCallID # TapiDial('123456',_TapiReturnCallID).
Da die Call-ID des ausgehenden Anrufes nun bekannt ist, können die Ereignisse im EvtTapi
entsprechend gefiltert werden.
sub EvtTapi
(
aEvt : event;
aTapiDevice : handle;
aCallID : int;
...
)
: logic;
{
if (gCallID > 0 and aCallID = gCallID)
{
// Ereignis wurde durch asynchrones TapiDial ausgelöst.
...
}
else
{
// Monitoring-Ereignis
...
}
...
}
Eine Antwort
Eine zusätzliche Herausforderung, wenn TapiDial und TapiListen in verschiedenen Threads oder Prozessen laufen