State

L’état de session ou d’appel indique le status actuel d’une session, par exemple « offre » ou « connecté ». Une gestion correcte des informations d’état est essentielle au bon fonctionnement de la plupart des applications TAPI. Par exemple, l’opération de réponse ne peut être effectuée que sur une session proposée, mais un transfert échoue si la session est dans cet état.

L’état d’une session change à la suite d’événements. Les événements peuvent être sollicités ou non sollicités. Les événements sollicités sont causés par l’application contrôlant la session, par exemple lorsqu’elle appelle une opération de session TAPI. Les événements non sollicités sont causés par le commutateur, le réseau téléphonique, l’utilisateur appuyant sur les boutons du téléphone local ou les actions de la partie distante.

Chaque fois qu’un fournisseur de services détecte un changement d’état de session, il signale la modification à TAPI et TAPI émet une notification d’événement à toutes les applications propriétaires et de surveillance. L’application doit réagir correctement à ces notifications. Consultez Notification d’événement sous Initialisation TAPI pour plus d’informations sur le contrôle des événements signalés à une application.

Une application doit toujours traiter les notifications d’événements d’état. Les transitions d’état valides pour une configuration physique peuvent être non valides pour une autre. Par exemple, considérez une ligne qui s’arrête physiquement à la fois sur l’ordinateur et sur un téléphone distinct, ce qui crée une configuration de ligne de partie entre l’ordinateur et l’ensemble téléphonique. Une application s’exécutant sur l’ordinateur peut ne pas connaître les activités de l’ensemble de téléphones. Autrement dit, la ligne peut être utilisée sans que le fournisseur de services en soit informé. Une application qui tente d’effectuer un appel sortant réussit à allouer une apparence d’appel à partir de TAPI, mais cela entraîne le partage de l’appel actif sur la ligne. L’envoi aveugle d’une chaîne de numérotation DTMF sans vérifier d’abord la tonalité d’un cadran peut ne pas entraîner un comportement intentionnel (ou poli).

Une application ne doit pas supposer une progression rigide d’un état à un autre. Les événements d’état arrivent et sont transférés de manière asynchrone, et les notifications peuvent ne pas être reçues dans un ordre prévisible. Par conséquent, les notifications d’état d’appel doivent être considérées comme indiquant à l’application le nouvel état de l’appel au lieu de signaler les transitions entre deux états.

Tous les fournisseurs de services de téléphonie doivent fournir ces informations.

**TAPI 2.x : **lineGetCallStatus, lineGetCallInfo, LINE_CALLSTATE message, LINECALLSTATE_ Constantes

**TAPI 3.x : **ITCallInfo::get_CallInfoLong (membre CIL_CALLID de CALLINFO_LONG), notification ITCallStateEvent , CALL_STATE énumérateur