Partager via


Vue d’ensemble du fournisseur de services TAPI

Les applications TAPI résident dans leur propre espace de processus. Les applications TAPI chargent les Tapi32.dll ou Tapi3.dll dans leur processus, et TAPI communique avec TAPISRV via une interface RPC privée. Un TSP s’exécute dans le contexte de TAPISRV. Un TSP donné peut résider sur un ordinateur autre que l’ordinateur de l’utilisateur et est accessible à l’aide d’un TSP distant. TAPISRV est implémenté en tant que processus de service dans SVCHOST. Un MSP se trouve dans l’espace de processus de l’application et est toujours local.

Une paire TSP/MSP peut être considérée comme ayant un chemin de communication privé virtuel. Les informations peuvent être envoyées entre les deux à l’aide de mémoires tampons opaques qui ne sont pas interprétées par TAPISRV ou la DLL TAPI.

Certains fournisseurs de services implémentent des opérations spécifiques au matériel impliqué. TAPI 2.x permet d’accéder à ces opérations via la fonction lineDevSpecific ou phoneDevSpecific . TAPI 3.x expose des interfaces spécifiques au fournisseur.

Le diagramme suivant illustre le flux des contrôles et des informations, montrant un TSP autonome (Unimodem) et une paire TSP/MSP (H.323).

flux tsp/msp autonome et appairé tsp/msp de contrôle et d’informations

Le diagramme suivant illustre la progression d’un appel entrant qui implique à la fois un TSP et un MSP.

appel entrant avec un tsp et un msp

Configuration des appels entrants

  • Le TSP envoie un message LINE_NEWCALL à TAPISRV. L’état de l’appel est LINECALLSTATE_OFFERING.
  • TAPISRV avertit les clients de l’appel.
  • TAPI3 crée l’objet APPEL TAPI, puis appelle ITMSPAddress::CreateMSPCall, qui est implémenté par le MSP.
  • Le MSP crée un objet d’appel MSP et des flux par défaut en fonction des types de médias requis pour l’appel. Elle retourne un pointeur IUnknown vers l’objet d’appel MSP.
  • TAPI3 agrège l’objet MSP Call dans l’objet APPEL TAPI, rendant ainsi les interfaces telles que ITStreamControl disponibles pour l’application. Il notifie ensuite l’application du nouvel appel.

L’application peut ensuite utiliser des méthodes telles que ITStream::SelectTerminal pour effectuer les préparations à la fin de l’appel.

Saisie semi-automatique des appels entrants

  • L’application appelle ITBasicCallControl::Answer.
  • TAPI3 appelle lineAnswer.
  • TAPISERV appelle TSPI_lineAnswer.
  • Le TSP lance la diffusion en continu des appels. En règle générale, le fournisseur de services TSP envoie un message au MSP correspondant, et le msp démarre les flux. Dans certaines implémentations TSP/MSP, le TSP démarre les flux.

Communication TSP/MSP pendant la progression de l’appel

Une fois l’appel en cours, le TSP et le MSP communiquent en passant des mémoires tampons opaques via TAPISRV et TAPI3.

  • Le TSP envoie des informations au MSP en envoyant le message LINE_SENDMSPDATA à TAPISRV.
  • Le MSP reçoit des informations du TSP via la méthode ITMSPAddress::ReceiveTSPData . Si les données sont liées à un objet d’appel MSP, un pointeur d’interface vers l’objet d’appel MSP est fourni en tant que paramètre de cette méthode.
  • Le MSP envoie des informations au fournisseur de services TSP en envoyant un événement MSP_TSP_DATA à TAPI 3.
  • Le TSP reçoit des informations du MSP via la fonction TSPI_lineReceiveMSPData .

Le processus et le contenu exacts de la communication entre les fournisseurs de services sont spécifiques à un ensemble TSP/MSP donné.

Notes

Pour les appels sortants, le MSP connaît généralement l’appel avant le TSP. Si le FOURNISSEUR de services de sécurité tente de communiquer avec le fournisseur de services avant qu’il ne soit informé d’un appel, la communication échoue. Lorsque le msp et le fournisseur de services de sécurité doivent échanger des informations concernant un appel spécifique, il doit lancer la communication.