Remises
Lorsqu’une application possède un propriétaire privilège pour une session de communication, l’application peut choisir de remettre la propriété à une autre application. L’opération de transfert est normalement utilisée pour permettre la modification du type de média de l’appel. L’application de priorité la plus élevée pour le nouveau type de média doit prendre et gérer l’appel. La modification du type de média se produit généralement pour l’une des raisons suivantes.
commande Utilisateur : Via une interface utilisateur ou des messages de fenêtre, l’application apprend que l’utilisateur local souhaite modifier le type de média. Par exemple, l’utilisateur a indiqué à la nouvelle application cible (qui n’est pas encore propriétaire) d’obtenir un appel vocal existant pour transmettre des données. L’application cible doit maintenant prendre le contrôle de l’appel. Dans ce cas, le propriétaire actuel remarque que le nombre de propriétaires augmente, puis abandonne son contrôle de l’appel. L’utilisateur peut également demander au propriétaire actuel de l’appel de le remettre à une application capable de gérer le nouveau type de média.
modification du type de média : le fournisseur de services peut détecter une modification de type multimédia. Par exemple, l’application locale joue un message vocal enregistré à l’appelant. Pendant ce message, l’appelant décide spontanément de transmettre un ton d’appel de télécopie, et l’application locale peut répondre en conséquence en changeant le type de média en télécopie et, si nécessaire, la remise de l’appel à une application de télécopie. Une autre façon de fonctionner consiste à utiliser une application de surveillance pour activer la surveillance du type de média et, lorsque le type multimédia dans lequel il est intéressé est détecté lors d’un appel, il peut demander la propriété de l’appel. Ce mécanisme rend inutile pour chaque application de surveiller chaque appel pour chaque type de média.
commande de partie distante : La partie distante peut indiquer de manière interactive une modification des types de supports lors d’un appel existant, par exemple si l’application locale surveille l’entrée DTMF par l’appelant distant. Grâce à cette surveillance, l’appelant indique, par exemple, qu’une télécopie est sur le point d’être envoyée. D’autres méthodes permettent à l’appelant de contrôler les applications locales avec des commandes reçues sur d’autres connexions de données et via des messages d’informations utilisateur-utilisateur ISDN.
Un transfert d’appel aura l’un des résultats suivants :
- L’appel est donné à une autre application (SUCCESS).
- L’application de remise est elle-même la cible (TARGETSELF).
- Le transfert échoue (TARGETNOTFOUND).
Si l’application qui reçoit l’appel remis a déjà un handle d’appel à l’appel, cet ancien handle d’appel est utilisé. Sinon, un nouveau handle d’appel est créé. Dans les deux cas, l’application se retrouve avec des privilèges de propriétaire pour l’appel. Chaque fois que l’application de transfert n’est pas la même que l’application cible, la cible est informée du transfert dans un message d’état de session comme s’il recevait un nouvel appel.
Si l’application propriétaire actuelle est appelée à modifier les types de supports, elle le fait en lui attribuant l’appel à une application utilisée pour le type de média cible. Les deux types de documents d’appel sont décrits dans de handoffs dirigés et types de documents multimédias.
Tous les fournisseurs de services ne prennent pas en charge l’utilisation de cette opération.
TAPI 2.x : Voir lineHandoff, avec lpszFileName défini sur le nom de l’application pour un transfert direct ou dwMediaMode défini sur un type de média pour un transfert indirect.
TAPI 3.x : Voir ITBasicCallControl ::HandoffDirect, ITBasicCallControl ::HandoffIndirect.
Remises dirigées
Une de transfert dirigée a lieu lorsque l’application cible est connue par nom de l’application d’origine. Cette situation se produit, par exemple, parmi un ensemble d’applications écrites par le même fournisseur. L’utilisateur peut généralement configurer le contrôle des remises dirigées. Avec un tel transfert, l’appel est donné à l’application spécifiée s’il a ouvert la ligne sur laquelle l’appel existe. Type de média spécifié au moment où l’application a ouvert la ligne est ignorée. Un exemple courant est un appel vocal suivi d’une transmission de télécopie dans le même appel. Le transfert dirigé serait le plus souvent utilisé par les applications du même développeur qui sont liées de différentes manières.
Le transfert dirigé peut également être utilisé dans les versions ultérieures dans le cadre du processus d’arbitrage de plusieurs applications en attente d’appels entrants du même type de média, avec la sélection de l’application pour gérer l’appel en fonction de la liaison de données ou de la détection de protocole de niveau supérieur plutôt que du type de média. Par exemple, il s’agit d’une ligne de modem de données entrante avec des applications telles que la prise en charge à distance, la carte d’affichage, l’accès au réseau distant et l’accès par courrier électronique distant en attente simultanée d’appels.
Handoffs de type de média
Un transfert de type média a lieu lorsqu’il existe un nouveau type de média ciblé, généralement lorsque l’application propriétaire détermine que le type de média nécessaire pour l’appel n’est pas présent ou est sur le point de changer.
Le processus d’un transfert dépendant du média peut être un processus de détection si le type de média UNKNOWN bit est activé. Il incombe à l’application propriétaire de parcourir les types de supports pour trouver l’application de priorité la plus élevée. TAPI effectue ce vélo uniquement sur l’appel entrant initial pour trouver le premier propriétaire. Il ne le fait pas pour une opération de transfert. Sinon, un transfert est pratiquement identique à celui de l’affectation initiale d’un appel à une application. La différence est le fait qu’un seul type de média peut être défini pour un transfert indirect (type de média).
Étant donné qu’un seul bit de type multimédia peut être spécifié, l’appel est attribué à l’application de priorité la plus élevée pour ce type de média. Toutefois, il est possible que plusieurs types de supports soient pris en compte pour le transfert. Dans ce cas, l’application de remise doit spécifier la priorité la plus élevée des types multimédias possibles en tant que paramètre.
Si une application spécifie le bit UNKNOWN lors de l’exécution d’un transfert de type média et que le transfert échoue, cela signifie qu’une application inconnue capable d’effectuer la détermination du type multimédia n’est pas en cours d’exécution. L’application qui est remise doit ensuite essayer de remettre l’appel à l’application de priorité la plus élevée inscrite pour le type de média supérieur suivant.
L’application de réception est désormais responsable de l’appel. Il sonde désormais le type de média réel de l’appel. Si l’application peut gérer le type de média de l’appel, elle doit s’assurer qu’elle est l’application de priorité la plus élevée inscrite pour ce type de média. Si c’est le cas, il conserve l’appel et le traite normalement. Si ce n’est pas le cas, il remet l’appel à une autre application inscrite pour ce type de média.
Si, toutefois, la sonde pour ce type de média échoue, l’application effectue à nouveau des sondes, en essayant les possibilités restantes en mode multimédia. Il doit d’abord désactiver le bit de type multimédia actuel, puis essayer un autre transfert avec un autre type.
Ce processus de détection et de remise continue, et les types de médias restants sont éliminés un par un. Le long de la route, l’une des applications peut voir que le type de média qu’il gère est sur l’appel, et que le transfert est réussi.
L’application doit ensuite définir le type de média correct et effacer tous les autres bits de type média. Cela informe d’autres applications intéressées du type de média approprié. Ces autres applications reçoivent un message de notification d’événement indiquant que le type de média de l’appel a changé.