10. Considérations de provisionnement (Provisioning Considerations)

Les UA peuvent découvrir automatiquement si cette fonctionnalité est active pour un AOR en recherchant le paramètre de champ d'en-tête d'événement 'shared' dans une réponse à un SUBSCRIBE de package de dialogue à l'AOR, donc aucun provisionnement n'est nécessaire pour cela.

Le registraire devra être provisionné pour accepter les enregistrements de première ou de tierce partie pour l'AOR partagé. L'enregistrement de première partie signifie que les URI To et From dans la requête REGISTER sont l'URI AOR partagé. L'enregistrement de tierce partie signifie que l'URI To est l'URI AOR partagé et que l'URI From est un AOR différent, peut-être celui de l'utilisateur individuel. Soit les informations d'identification de l'AOR partagé, soit celles de l'utilisateur DOIVENT (MUST) être acceptées par le registraire et l'agent d'apparence, selon la politique d'autorisation en place pour le domaine.

Si l'agent d'apparence doit s'abonner à l'état de dialogue des UA, alors l'agent d'apparence et les UA doivent être provisionnés avec des informations d'identification afin que les UA puissent authentifier l'agent d'apparence.

Dans certains cas, les UA du groupe d'apparence partagée peuvent avoir une limitation d'interface utilisateur sur le nombre d'apparences pouvant être rendues. En général, il s'agira de téléphones fixes avec boutons/lampes au lieu d'interfaces utilisateur plus flexibles. Dans ce cas, il peut être utile pour l'agent d'apparence de connaître ce nombre maximum. Cela peut permettre à l'agent d'apparence d'appliquer une politique lorsque cette limite est atteinte, par exemple refuser un appel. Cependant, ce mécanisme ne fournit aucun moyen de découvrir cela par des moyens de protocole.