8. Considérations relatives à l'interface utilisateur (User Interface Considerations)
Le numéro d'apparence alloué à un appel est un concept important qui permet aux appels d'être gérés par plusieurs dispositifs avec des interfaces utilisateur hétérogènes d'une manière qui permet toujours aux utilisateurs de voir un modèle cohérent. Un traitement soigneux du numéro d'apparence est essentiel pour répondre aux attentes des utilisateurs. De plus, le rendu du bon état d'appel/apparence aux utilisateurs est également important.
8.1. Rendu du numéro d'apparence (Appearance Number Rendering)
Étant donné que différents UA ont différentes capacités d'interface utilisateur, il est courant de constater que certains UA ont des restrictions que d'autres n'ont pas. Une interopérabilité parfaite entre tous les UA n'est clairement pas possible, mais grâce à une conception soigneuse, l'interopérabilité jusqu'aux limites de chaque UA peut être atteinte.
Les directives suivantes suggèrent comment le numéro d'apparence devrait être traité dans trois implémentations typiques d'interface utilisateur.
8.1.1. UA à apparence unique (Single Appearance UAs)
Ces dispositifs sont limités par le fait qu'ils n'ont que la capacité d'afficher les indications d'état pour une seule apparence. Le UA DEVRAIT (SHOULD) toujours envoyer des messages annotés avec le numéro d'apparence "1". Toute indication d'appel pour des apparences autres que le numéro "1" DEVRAIT (SHOULD) être rejetée avec une réponse 480 (Temporarily Unavailable, temporairement indisponible) ou 486 (Busy Here, occupé ici). Notez que cela signifie qu'un UA à apparence unique ne peut pas répondre à son propre appel vers l'AOR partagé, car cet appel utiliserait un deuxième numéro d'apparence.
8.1.2. UA à double apparence (Dual Appearance UAs)
Ces dispositifs sont essentiellement des téléphones à apparence unique qui implémentent l'appel en attente. Ils ont une interface utilisateur très simple qui leur permet de basculer entre deux apparences (bascule ou crochet flash) et peut-être des tonalités audibles pour indiquer l'état de l'autre apparence. Seuls les numéros d'apparence "1" et "2" seront utilisés par ces UA.
8.1.3. UA à apparence partagée avec numéro d'apparence fixe (Shared Appearance UAs with Fixed Appearance Number)
Ce UA est le téléphone fixe typique de "classe affaires". Un certain nombre d'apparences sont généralement configurées de manière statique et étiquetées sur les boutons, et les appels peuvent être gérés à l'aide de ces apparences configurées. Tous les appels en dehors de cette plage doivent être rejetés et non mappés à un bouton libre. Les utilisateurs de ces dispositifs saisissent souvent des numéros d'apparence spécifiques pour les appels sortants, et le UA devra saisir le numéro d'apparence et attendre la confirmation de l'agent d'apparence avant de procéder aux appels.
8.1.4. UA à apparence partagée avec numéros d'apparence variables (Shared Appearance UAs with Variable Appearance Numbers)
Ce UA est généralement un softphone ou un téléphone fixe avec une interface utilisateur graphiquement riche. Dans ces cas, même l'idée d'un index d'apparence peut sembler inutile. Cependant, pour que ces téléphones puissent interagir avec succès avec d'autres types de téléphones, il est important qu'ils utilisent toujours l'index d'apparence pour régir l'ordre d'apparition des appels en cours. Aucune directive spécifique sur la présentation n'est donnée, sauf que l'ordre doit être cohérent. Ces dispositifs peuvent généralement passer des appels sans attendre la confirmation de l'agent d'apparence sur le numéro d'apparence.
8.1.5. Exemples de problèmes d'interface utilisateur (Example User Interface Issues)
Les problèmes rencontrés par chaque style d'interface utilisateur sont facilement visibles dans cet exemple:
-
Un appel arrive au groupe d'apparence partagée et se voit attribuer un numéro d'apparence "1". Tous les UA devraient être en mesure de rendre à l'utilisateur l'arrivée de cet appel.
-
Un autre appel arrive au groupe d'apparence partagée et se voit attribuer un numéro d'apparence "2". Le UA à apparence unique ne devrait pas présenter cet appel à l'utilisateur. Les autres UA ne devraient avoir aucun problème à présenter cet appel de manière distincte du premier appel.
-
Le premier appel se termine, libérant le numéro d'apparence "1". Le UA à apparence unique devrait maintenant indiquer qu'il n'y a pas d'appels car il est incapable de gérer les appels autres que sur la première apparence. Les deux UA à apparence partagée devraient clairement montrer que le numéro d'apparence "1" est maintenant libre, mais qu'il y a toujours un appel sur le numéro d'apparence "2".
-
Un troisième appel arrive et se voit attribuer le numéro d'apparence "1". Tous les UA devraient être en mesure de rendre l'arrivée de ce nouvel appel à l'utilisateur. Les UA à apparences multiples devraient continuer à indiquer la présence du deuxième appel, et ils devraient également s'assurer que l'ordre de présentation est lié au numéro d'apparence et non à l'ordre d'arrivée des appels.
8.2. Rendu de l'état d'appel (Call State Rendering)
Les UA qui implémentent la fonctionnalité d'apparences partagées ont généralement une interface utilisateur qui fournit l'état des autres apparences dans le groupe. Lorsque les NOTIFY d'état de dialogue de l'agent d'apparence sont traités, ces informations peuvent être rendues. Même l'interface utilisateur la plus simple a généralement trois états: inactif, actif et en attente. L'état inactif, généralement indiqué par une lampe éteinte, est indiqué pour une apparence lorsque le numéro d'apparence n'est associé à aucun dialogue, comme indiqué par l'agent d'apparence. L'état actif, généralement indiqué par une lampe allumée, signifie qu'un numéro d'apparence est associé à au moins un dialogue, comme indiqué par l'agent d'apparence. L'état en attente, souvent indiqué par une lampe clignotante, signifie que l'état d'appel du point de vue du UA dans le groupe d'apparence partagée est en attente. Cela peut être déterminé par la présence de la balise de fonctionnalité "+sip.rendering=no" [RFC3840] avec l'URI cible local. Notez que l'état en attente de l'URI cible distant n'est pas pertinent pour cet affichage. Pour les dialogues joints, l'état est rendu comme en attente uniquement si tous les URI cibles locaux sont indiqués avec la balise de fonctionnalité "+sip.rendering=no".