Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’état de session ou d’appel indique l’état actuel d’une session, par exemple « offre » ou « connecté ». La gestion appropriée des informations d’état est essentielle au bon fonctionnement de la plupart des applications TAPI. Par exemple, l’opération de réponse peut être effectuée uniquement 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. é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, les boutons d’appui de l’utilisateur sur le téléphone local ou les actions du tiers distant.
Chaque fois qu’un fournisseur de services détecte une modification d’état de session, il signale la modification apportée à TAPI et TAPI émet une notification d’événement à tous les propriétaires et à surveiller les applications. L’application doit réagir de manière appropriée à ces notifications. Consultez notification d’événement sous d’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 ne pas être valides pour une autre. Par exemple, considérez une ligne qui se termine physiquement à la fois sur l’ordinateur et sur un ensemble téléphonique distinct, créant une configuration de ligne tierce entre l’ordinateur et l’ensemble de téléphones. Une application s’exécutant sur l’ordinateur peut ne pas connaître les activités de définition de téléphone. Autrement dit, la ligne peut être utilisée sans que le fournisseur de services ne le sache. 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 un ton de numérotation peut ne pas entraîner le comportement prévu (ou poli).
Une application ne doit pas supposer une progression rigide d’un état à l’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 vues 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, message LINE_CALLSTATE, constantes LINECALLSTATE_
**TAPI 3.x : **ITCallInfo ::get_CallInfoLong ( membreCIL_CALLID de CALLINFO_LONG), notification ITCallStateEvent, énumérateur CALL_STATE