Remises
Lorsqu’une application dispose du privilège de propriétaire pour une session de communication, l’application peut choisir de transmettre la propriété à une autre application. L’opération de remise 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. Le changement de type de média se produit généralement pour l’une des raisons suivantes.
Commande utilisateur : Par le biais d’une interface utilisateur ou de messages de fenêtre, l’application apprend que l’utilisateur local souhaite modifier le type de média. Par exemple, l’utilisateur a demandé à 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 sur l’appel. L’utilisateur peut également demander au propriétaire actuel de l’appel de le transmettre à une application capable de gérer le nouveau type de média.
Changement de type de média : Le fournisseur de services peut détecter un changement de type de média. Par exemple, l’application locale lit un message vocal enregistré à l’appelant. Pendant ce message, l’appelant décide spontanément de transmettre une tonalité d’appel de télécopie, et l’application locale peut répondre en conséquence en changeant le type de support par télécopie et, si nécessaire, en passant l’appel à une application de télécopie. Une autre façon de procéder consiste pour une application de supervision à activer la surveillance du type de média et, lorsque le type de média qui l’intéresse est détecté sur un appel, elle 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 un changement dans les types de médias au cours 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. L’appelant peut également contrôler les applications locales avec les commandes reçues sur d’autres connexions de données et par le biais de 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 de remise a déjà un handle d’appel pour 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 sur l’appel. Chaque fois que l’application de remise n’est pas la même que l’application cible, la cible est informée de la remise dans un message d’état de session comme si elle recevait un nouvel appel.
Si l’application propriétaire actuelle est appelée à modifier les types de médias, elle le fait en remettant l’appel à une application utilisée pour le type de média cible. Les deux types de remises d’appel sont décrits dans Handoffs dirigés et Handoffs de type média.
Tous les fournisseurs de services ne prennent pas en charge l’utilisation de cette opération.
TAPI 2.x : Consultez 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 : Consultez ITBasicCallControl::HandoffDirect, ITBasicCallControl::HandoffIndirect.
Remises dirigées
Un transfert dirigé 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 si elle a ouvert la ligne sur laquelle l’appel existe. Le type de média spécifié au moment où l’application a ouvert la ligne est ignoré. 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 également liées d’autres 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, la sélection de l’application pour gérer l’appel étant basée sur la détection de protocole de liaison de données ou de niveau supérieur plutôt que sur le type de média. Un exemple de son utilisation serait une ligne de modem de données entrante avec des applications telles que la prise de contrôle à distance, le tableau d’affichage, l’accès au réseau à distance et l’accès à la messagerie à distance en attente d’appels simultanément.
Handoffs de type multimédia
Un transfert de type multimé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 à 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 d’interrogation si le type de média unknown bit est activé. Il incombe à l’application propriétaire de parcourir les types de médias pour rechercher l’application de priorité la plus élevée. TAPI effectue ce cycle uniquement sur l’appel entrant initial pour rechercher le premier propriétaire. Il ne le fait pas pour une opération de remise. Sinon, un transfert est pratiquement le même que pour l’affectation initiale d’un appel à une application. La différence réside dans 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 donné à l’application de priorité la plus élevée pour ce type de média. Toutefois, il est possible que plusieurs types de médias 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 de mé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 multimédia et que le transfert échoue, cela signifie qu’une application inconnue capable d’effectuer la détermination du type de média n’est pas en cours d’exécution. L’application qui est en cours de 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’il s’agit de 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 désactivé à une autre application inscrite pour ce type de média.
Si, toutefois, la sonde pour ce type de média échoue, l’application sonde à nouveau, en essayant les autres possibilités de 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 d’interrogation et de remise se poursuit, et les autres types de médias sont éliminés un par un. En cours de route, l’une des applications peut voir que le type de média qu’elle 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 multimédia. Cela informe les 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é.