9. Interopérabilité avec les UA à apparence non partagée (Interoperability with Non-shared Appearance UAs)
Il est souhaitable de permettre à un UA de base qui ne prend pas directement en charge l'apparence partagée de faire partie d'un groupe d'apparence partagée. Pour prendre en charge cela, le proxy doit collaborer avec l'agent d'apparence. Ceci n'est pas requis dans l'architecture de base d'apparence partagée; par conséquent, l'interopérabilité de l'apparence partagée avec les UA à apparence non partagée ne sera pas disponible dans tous les déploiements d'apparence partagée.
Tout d'abord, un UA qui ne prend pas en charge les événements de dialogue ou la fonctionnalité d'apparences partagées sera discuté. Ensuite, un UA qui prend en charge les événements de dialogue mais pas la fonctionnalité d'apparences partagées sera discuté.
9.1. Attribution d'apparence (Appearance Assignment)
Un UA qui n'a aucune connaissance des apparences n'aura des numéros d'apparence pour les appels sortants que s'ils sont attribués par l'agent d'apparence. Si le UA à apparence non partagée ne prend pas en charge Join ou Replaces, tous les dialogues DEVRAIENT (SHOULD) être marqués "exclusive" (exclusifs) pour indiquer que ces options ne sont pas disponibles. Marquer ces dialogues comme "exclusive" offre une meilleure expérience utilisateur et évite des échecs supplémentaires de messagerie SIP.
9.2. Libération d'apparence (Appearance Release)
Dans tous les cas, l'agent d'apparence doit être conscient de la durée de vie du dialogue pour libérer les apparences dans le groupe.
Il est également souhaitable que tout changement d'état de dialogue (tel que la mise en attente, etc.) soit rendu disponible aux autres UA du groupe via le package d'événements de dialogue. Si l'agent d'apparence inclut un proxy qui effectue Record-Route pour les dialogues provenant du UA non conscient de l'apparence partagée, l'agent d'apparence connaîtra l'état des dialogues, y compris la mise en attente, etc. Ces informations pourraient être déterminées à partir de l'inspection des messages INVITE et re-INVITE non chiffrés de bout en bout et ajoutées aux informations de dialogue transmises aux autres UA.
9.3. UA prenant en charge les événements de dialogue mais pas l'apparence partagée (UAs Supporting Dialog Events but Not Shared Appearance)
L'interopérabilité avec les UA qui prennent en charge les événements de dialogue mais pas la fonctionnalité d'apparences partagées est plus simple. Comme auparavant, toutes les attributions de numéros d'apparence doivent être effectuées par l'agent d'apparence. L'agent d'apparence DEVRAIT (SHOULD) toujours inclure les informations d'apparence dans les NOTIFY -- ce UA ignorera simplement ces informations supplémentaires. Ce type de UA ignorera également les limitations de numéros d'apparence et peut tenter de joindre ou de remplacer des dialogues marqués exclusifs. En conséquence, le proxy ou les UA doivent rejeter de telles demandes, sinon les dialogues seront joints ou pris.