Cycle de vie d’un fournisseur de services de téléphonie

Cette rubrique fournit une révision générale des opérations TSP.

Une session est la durée pendant laquelle une configuration particulière reste valide et des opérations de téléphonie sont effectuées. Un fournisseur de services peut prendre en charge de nombreuses sessions entre le moment où il est chargé pour la première fois et le moment où il est finalement libéré. Pour chaque session, TAPI négocie la version de l’interface, démarre la session, effectue des opérations et finit par arrêter la session. Le fournisseur de services ne doit pas conserver les informations d’une session à l’autre.

Une fois la version de l’interface connue, TAPI appelle la fonction TSPI_providerInit pour définir tous les paramètres opérationnels. Le fournisseur de services s’assure que toutes les informations de configuration dans le Registre sont stables lorsque la fonction TSPI_providerInit est appelée. La plupart des fournisseurs de services lisent toutes les informations de configuration à ce moment-là.

Les opérations normales peuvent se dérouler dans n’importe quel ordre, après l’initialisation du fournisseur de services.

TAPI négocie les informations spécifiques à l’appareil par appareil. TAPI et le fournisseur de services valident une version lors de l’ouverture d’un appareil.

Le fournisseur de services peut recevoir des demandes de sélection et d’annulation de versions d’extension. Lorsqu’une version d’extension est sélectionnée, l’appareil fonctionne strictement en fonction de cette version d’extension spécifique à l’appareil.

La négociation d’une version d’extension spécifique à l’appareil peut se produire plusieurs fois, avant et après l’ouverture de l’appareil. TAPI transmet une plage de versions, et le fournisseur de services choisit et retourne une valeur à partir de cette plage. Normalement, les extensions spécifiques à l’appareil sont désactivées pour le fournisseur de services.

Cela valide tapi et le fournisseur de services à fonctionner au niveau de cette version d’extension jusqu’à ce que la sélection soit annulée. Pendant la durée d’application d’une extension spécifique à l’appareil, une tentative de négociation d’un niveau de version d’extension doit autoriser uniquement le niveau de version actuellement en vigueur. Une fois l’extension spécifique à l’appareil annulée, une autre version peut être négociée et sélectionnée.

Les opérations téléphoniques dans la paire Ouvrir/Fermer sont illustrées dans l’illustration suivante. Certaines de ces opérations sont synchrones, d’autres sont asynchrones. Si une opération se termine de manière asynchrone, une autre opération peut être demandée avant l’achèvement du premier rapport. Ainsi, les opérations peuvent se chevaucher de n’importe quelle manière. Le fournisseur de services doit éventuellement signaler l’achèvement de toute opération asynchrone demandée. La fermeture d’un téléphone force l’exécution des opérations asynchrones en attente (éventuellement avec une indication de « défaillance »).

Le cycle de vie des appareils en ligne est similaire au cycle de vie des téléphones, à ceci près que les lignes ont leurs propres procédures de négociation, d’initialisation, d’ouverture et de fermeture. Les opérations sur les lignes ouvertes sont placées entre crochets par leur propre paire Ouvrir/Fermer . Cette paire est à son tour entre crochets entre la même paire Initialisation/Arrêt que le téléphone Ouvrir/Fermer.

Les cycles de vie des appels sont strictement placés entre crochets entre l’ouverture/la fermeture de la ligne qui les contient. La durée de vie des appels peut commencer de plusieurs façons :

• Demandé à partir de TAPI via des fonctions telles que lineMakeCall, lineSetupTransfer ou lineSetupConference.
• Spontanément provenant du fournisseur de services sous la forme de nouveaux appels entrants, d’appels lancés par l’utilisateur sur un combiné téléphonique attaché ou d’appels générés comme un effet secondaire d’autres opérations telles que la mise en attente d’un appel existant.

Les durées de vie des appels distincts au sein d’une même ligne peuvent se chevaucher de quelque manière que ce soit. Tous les appels terminent leur durée de vie au moment où la fonction TSPI TSPI_lineCloseCall est appelée. Le cycle de vie de plusieurs appels est illustré dans l’illustration suivante.

Un appel peut provenir de TAPI, comme indiqué avec la paire MakeCall/CloseCall . Un appel peut également provenir du fournisseur de services. Le fournisseur de services l’annonce avec un message LINE_NEWCALL à une procédure de rappel fournie par TAPI. Dans ce cas, TAPI retourne son identificateur pour l’appel, qui est inclus dans les rappels suivants rapportant des événements se produisant sur l’appel. Dans le cas d’appels dont la durée de vie provient de TAPI, cet identificateur est inclus dans l’opération TSPI qui crée l’appel.

Toutes les opérations qui démarrent la durée de vie d’un appel entraînent l’échange d’identificateurs TAPI et du fournisseur de services pour le nouvel appel. Dans le cas d’appels provenant de TAPI, TAPI transmet son identificateur et reçoit l’identificateur du fournisseur de services en tant que paramètre de retour. Dans le cas où l’appel provient du fournisseur de services, celui-ci transmet son identificateur à TAPI et reçoit l’identificateur TAPI en tant que paramètre de retour.

L’illustration suivante offre une vue d’ensemble de l’installation, de la configuration et de la suppression du fournisseur de services . séquences de cycle de vie qui s’étendent sur de nombreuses sessions. Le cycle de vie standard de ces opérations peut être affiché avec la ligne de temps suivante.

Le cycle de vie d’installation et de suppression standard s’affiche, couvrant plusieurs sessions. Les appels aux procédures d’installation et de suppression sont strictement couplés et ne se chevauchent pas. Les appels à la procédure Config peuvent se produire plusieurs fois au sein de cette paire. L’une d’elles est généralement effectuée par le fournisseur de services en tant qu’effet secondaire interne de la procédure d’installation pour créer des entrées de ligne et de téléphone. La procédure Config peut être appelée à d’autres moments pour modifier une configuration existante. La procédure d’installation doit être effectuée avant qu’une autre fonction TSPI ne soit autorisée. Dans le scénario idéal, toutes les sessions sont strictement imbriquées dans la paire de procédures Installer/Supprimer .

Les fonctions TSPI_providerInstall, TSPI_providerConfig et TSPI_providerRemove interagissent avec le fournisseur de services lui-même plutôt qu’avec un appareil spécifique. Elles affectent les informations de configuration statiques qui survivent sur plusieurs sessions et doivent être présentes pour que toute autre opération se poursuive. Ainsi, toutes les autres opérations sont imbriquées entre l’appel de TSPI_providerInstall et l’achèvement de son TSPI_providerRemove correspondant. Ces deux opérations se produisent généralement très loin les unes des autres, probablement dans une charge différente du fournisseur de services ou dans un démarrage différent de la machine. L’appel de la fonction Config en externe est facultatif, car la procédure d’installation est requise pour inclure le comportement config en plus du sien. La raison habituelle de l’appeler en externe est de modifier une configuration existante.

Il y a une subtilité dans le concept de réalisation d’une opération de TSPI_providerRemove . Il est souhaitable de permettre à l’utilisateur d’exécuter l’utilitaire de téléphonie Panneau de configuration fourni avec le service de téléphonie pour modifier les configurations du fournisseur de services, même lorsque des opérations de téléphonie (sessions) sont en cours. Par conséquent, les spécifications TSPI_providerConfig et TSPI_providerRemove permettent d’appeler pendant qu’il y a une session en suspens. Toutefois, toutes les modifications apportées à la configuration doivent être retardées jusqu’à ce que les opérations de téléphonie soient arrêtées et redémarrées. Ainsi, à proprement parler, l’achèvement d’une opération de TSPI_providerConfig ou de TSPI_providerRemove se produit en dehors de toute session. L’imbrication des actions est comme illustré dans la figure, même si les appels de procédures peuvent apparaître dans un ordre légèrement différent. Un fournisseur de services peut tout simplement interdire la configuration ou la suppression pendant que les opérations sont en cours, même si l’utilisateur doit être averti avec une boîte de dialogue. Une implémentation plus conviviale qui autorise au moins un sous-ensemble d’opérations est préférable.

Ces opérations d’installation, de configuration et de suppression ont tous l’effet secondaire de signaler les applications de téléphonie en cours d’exécution, ce qui les amène à arrêter leur utilisation du service de téléphonie. Ensemble, cela met fin à toutes les sessions en suspens pour les fournisseurs de services. Cela signifie aux fournisseurs de services qu’ils doivent lire la nouvelle configuration du Registre lorsque de nouvelles sessions commencent. Toutes les modifications en attente en raison d’une configuration ou d’une suppression pendant que les opérations étaient en cours prennent effet.