Architecture MSP

Dans l’architecture TAPI, tous les TSPs sont exécutés dans le contexte de TAPISRV, qui est implémenté en tant que processus de service dans SVCHOST. Les applications TAPI résident dans leur propre processus. Les applications TAPI chargent Tapi3.dll et les MSP nécessaires dans leur propre processus, et la DLL TAPI communique avec TAPISRV via une interface RPC privée. Le diagramme suivant illustre l’interaction de ces composants.

interactions entre tapisrv, les applications TAPI et les MSP

un fournisseur de services de média (MSP) fournit la diffusion multimédia en continu à l’aide des abstractions des terminaux, des Flux et des sous-flux.

Un terminal est un récepteur ou une source pour un flux de média. Il peut s’agir d’un objet physique, tel qu’un haut-parleur ou un microphone, ou d’une abstraction d’un appareil, telle qu’une fenêtre vidéo. L' objet terminal expose l’interface ITTerminal . La classe de terminal est décrite par le GUID de la classe terminal . Un MSP peut définir ses propres classes de terminaux.

Flux diviser le média d’un appel en fonction du type de média ou du type, de la directiondu flux et de l’adresse de destination du média. Par exemple, un flux audio entrant d’un modem est un objet de flux, un flux vidéo sortant vers une adresse IP et un port est un objet de flux, les flux vidéo provenant d’un groupe de multidiffusion IP sont également considérés comme un objet de flux. L’objet de flux est représenté par l’interface ITStreamControl .

Les sous-flux permettent un contrôle plus précis sur le média. Par exemple, dans le cas de la multidiffusion IP, l’objet flux vidéo entrant peut représenter plusieurs personnes. L’application souhaitera probablement que chaque participant ait un convertisseur distinct. Le flux vidéo entrant peut être divisé en plusieurs sous-flux, un pour chaque personne. Un sous-flux correspond à une personne et peut être configuré et contrôlé séparément. L’objet de sous-flux est représenté par l’interface ITSubStreamControl .

Quand une application appelle ITAddress :: createCall pour configurer un appel, elle doit spécifier le type de média requis. Sur un appel sortant, il indique simplement à TAPI une fois l’appel créé. Par exemple :

HRESULT hr = pAddress->CreateCall( 
       pszDestAddress, 
       lAddressType, 
       TAPIMEDIATYPE_AUDIO | TAPIMEDIATYPE_VIDEO, 
       &pCall 
       ); 
// If (hr != S_OK ) process the error here

Dans ce cas, l’application crée un appel audio-vidéo sortant.

Les types de média transmis indiquent le support qui intéresse l’application pendant la durée de vie de l’appel. Par exemple, l’application peut spécifier l’audio et la vidéo lors de la création de l’appel, mais ne sélectionner que des terminaux audio au début. Le MSP démarre uniquement la diffusion audio en continu, mais ne rejette pas une requête vidéo locale ou distante effectuée plus tard au cours de la durée de vie de l’appel.

lorsque l’application appelle ensuite ITBasicCallControl :: Connecter, TAPI 3 appelle TSPI _ lineMakeCall dans le TSP. Après l’établissement d’un appel, le MSP et le TSP peuvent communiquer en fonction des besoins.

Lors de la déconnexion d’un appel, il revient au MSP et au TSP de communiquer sur le déchirement de l’appel. Tapi3.dll appellera TSPI _ lineDrop si l’application appelle Disconnect.