Partager via


TSPI Messages

Cette section contient la liste des messages dans l’interface TSPI (Telephony Service Provider Interface). Ces messages sont utilisés pour notifier TAPI de l’occurrence d’événements asynchrones qui se produisent spontanément au sein du fournisseur de services. Le fournisseur de services transmet ces événements à TAPI en appelant une fonction de rappel LINEEVENT ou PHONEEVENT , selon que le fournisseur de services signale un événement sur une ligne, un appel ou un appareil téléphonique. La procédure LINEEVENT pour signaler les événements se produisant sur une ligne ou un appel est fournie au fournisseur de services au moment où la ligne est ouverte avec la fonction TSPI_lineOpen . La procédure PHONEEVENT pour signaler les événements se produisant sur un téléphone est fournie avec la fonction TSPI_phoneOpen .

Ces événements spontanés ne sont pas sollicités par TAPI dans le sens où ils ne constituent pas une réponse directe à une demande. Ces événements contrastent avec ceux qui signalent l’achèvement des demandes effectuées par TAPI. Ces événements d’achèvement sont signalés via la fonction de rappel ASYNC_COMPLETION .

Les profils de paramètres pour les procédures d’événements spontanés incluent des paramètres qui identifient l’objet pertinent pour lequel l’événement est signalé (téléphone, ligne ou appel). L’identification se présente sous la forme d’un handle opaque dont l’interprétation exacte n’est pas publiée par TSPI. TAPI détermine en interne la relation entre ces handles opaques et les structures de données utilisées pour représenter les appareils.

Le profil de paramètre pour les procédures événementielles spontanées inclut également un paramètre de message identifiant le type du message. Chaque type de message a une définition correspondante qui détermine les handles inclus, ainsi que d’autres paramètres et leurs significations. Il existe une correspondance très forte entre les messages qui apparaissent au niveau TSPI et ceux qui apparaissent au niveau TAPI. Voici les règles générales de correspondance :

  • L’ensemble de messages est presque identique. Lorsque les messages correspondent, le même nom et la même valeur de message sont utilisés au niveau TSPI.
  • Les handles apparaissant au niveau TSPI sont les types opaques définis par la spécification TSPI. Ces types (et leur interprétation) diffèrent de ceux au niveau TAPI, bien qu’ils fassent référence à la même classe d’appareil. Par exemple, lorsqu’un message TAPI inclut un handle HLINE, le message TSPI correspondant inclut généralement un handle HTAPILINE .
  • Aucune donnée dwCallbackInstance n’est passée au rappel.
  • Les paramètres dwParam1, dwParam2 et dwParam3 sont généralement identiques aux paramètres correspondants pour le message TAPI.
  • Les messages orientés ligne et orientés appels sont passés à une procédure de rappel différente de celle des messages orientés téléphone.

Pour chaque message, cette section répertorie les éléments suivants :

  • Objectif du message
  • Procédure de rappel à laquelle ce message est passé
  • Description des paramètres de message
  • Commentaires facultatifs sur l’utilisation du message
  • Références facultatives à d’autres fonctions, messages et structures de données
  • Commentaires facultatifs comparant ce message à l’interface TAPI

Certains messages sont utilisés pour avertir TAPI d’une modification de la status d’un objet. Ces messages fournissent le handle d’objet opaque TAPI et une indication du status élément qui a changé. TAPI peut ensuite appeler une fonction « get status » appropriée de l’objet pour obtenir la status complète de l’objet.

Lorsqu’un événement se produit, un message peut être envoyé ou non à TAPI. Pour certains types d’événements, tels que les modifications status, TAPI spécifie un ensemble de modifications status qui l’intéressent. Le fournisseur de services est invité à limiter les événements de message de modification status qu’il signale à ceux inclus dans cet ensemble. Le fournisseur de services n’est pas tenu de respecter cette limite. En d’autres termes, il peut signaler plus de modifications que ce qui est strictement nécessaire. Toutefois, il doit essayer de respecter la limite pour des raisons de performances.

Le message LINE_REPLY n’est pas utilisé au niveau TSPI. L’achèvement d’une requête asynchrone est signalé à l’aide du rappel ASYNC_COMPLETION .

Le message PHONE_REPLY n’est pas utilisé au niveau TSPI. L’achèvement d’une requête asynchrone est signalé à l’aide du rappel ASYNC_COMPLETION .

Pour plus d'informations, consultez les rubriques suivantes :