4. Exigences et mise en œuvre

La section suivante détaille les exigences et discute de la mise en œuvre de la fonctionnalité d'apparences partagées.

4.1. Exigences

Les exigences de base de la fonctionnalité d'apparences partagées peuvent être résumées comme suit:

REQ-1: Les appels entrants vers l'AOR doivent être proposés à un groupe d'UA et peuvent être répondus par n'importe lequel d'entre eux.

REQ-2: Chaque UA du groupe doit pouvoir connaître l'état des appels des autres dans le groupe dans le but de rendre cette information à l'utilisateur.

REQ-3: Un UA doit pouvoir rejoindre (également appelé pont ou conférence ensemble) ou prendre un appel actif d'un autre UA dans le groupe de manière sécurisée.

REQ-4: Le mécanisme devrait nécessiter une quantité minimale de configuration. Les UA s'enregistrant auprès de l'AOR de groupe devraient pouvoir participer au groupe d'apparence partagée sans configuration manuelle des membres du groupe.

REQ-5: Le mécanisme doit être extensible pour un grand nombre d'apparences et un grand nombre d'UA sans introduire de trafic de messagerie excessif.

REQ-6: Chaque appel ou session (entrant ou sortant) doit se voir attribuer un numéro "d'apparence" commun provenant d'un pool géré administré pour le groupe AOR. Une fois la session terminée, le numéro d'apparence est libéré dans le pool et peut être réutilisé par une autre session entrante ou sortante.

REQ-7: Chaque UA du groupe doit pouvoir connaître l'état de toutes les apparences du groupe.

REQ-8: Il doit exister des mécanismes pour résoudre les conflits d'apparence entre les UA du groupe. Le conflit dans ce contexte signifie qu'un numéro d'apparence est associé à plusieurs dialogues qui ne sont pas mélangés ou autrement associés.

REQ-9: Le mécanisme doit permettre à tous les UA recevant une demande de session entrante d'utiliser le même numéro d'apparence au moment de l'alerte.

REQ-10: Le mécanisme doit avoir un moyen de reconstruire l'état de l'apparence après une panne qui n'entraîne pas de trafic et de traitement excessifs.

REQ-11: Le mécanisme doit avoir une compatibilité descendante de sorte qu'un UA qui n'est pas au courant de la fonctionnalité puisse toujours s'enregistrer auprès de l'AOR de groupe et passer et recevoir des appels.

REQ-12: Le mécanisme ne doit pas permettre aux UA en dehors du groupe de sélectionner, saisir ou manipuler les numéros d'apparence.

REQ-13: Pour des raisons de confidentialité, il doit exister un mécanisme pour que les informations d'apparence ne soient pas divulguées en dehors du groupe d'UA (par exemple, "Alors, qui avez-vous sur la ligne 1?").

REQ-14: Le mécanisme doit prendre en charge un moyen pour les UA de demander l'exclusivité sur une apparence de ligne. L'exclusivité signifie que l'UA qui la demande souhaite une conversation privée avec la partie externe et que les autres UA ne doivent pas être autorisés à rejoindre ou à prendre l'appel. L'exclusivité peut être demandée au début d'une session entrante ou sortante ou pendant la session. Une demande d'exclusivité peut être acceptée ou rejetée par l'entité fournissant le service d'apparence partagée. Par conséquent, le mécanisme doit fournir un moyen de communiquer le résultat à l'UA demandeur.

REQ-15: Le mécanisme devrait prendre en charge un moyen pour un UA de saisir un numéro d'apparence particulier pour les demandes sortantes avant d'envoyer la demande réelle. C'est souvent appelé saisie.

REQ-16: Le mécanisme devrait prendre en charge un moyen pour un UA de saisir un numéro d'apparence particulier et d'envoyer également la demande en même temps. Cela est nécessaire lorsqu'une fonction d'appel automatique (un téléphone configuré pour composer immédiatement un numéro de téléphone lorsqu'il décroche) est combinée avec des apparences partagées. Dans ce cas, la saisie de la ligne est intégrée à la numérotation.

4.2. Mise en œuvre

Cette section discute de manière non normative de la mise en œuvre de la fonctionnalité d'apparences partagées. La description normative se trouve dans la section 5. De nombreuses exigences pour ce service peuvent être satisfaites en utilisant des mécanismes SIP standard tels que:

• Un proxy de bifurcation SIP et un registraire/service de localisation satisfont REQ-1.

• Le package de dialogue SIP satisfait REQ-2.

• La combinaison des champs d'en-tête SIP Replaces et Join satisfait REQ-3.

• L'utilisation d'un agent d'état pour le package de dialogue satisfait REQ-4 et REQ-5.

REQ-6 suggère la nécessité d'une entité qui gère la ressource d'apparence. Tout comme les systèmes de conférence ont généralement un point de contrôle unique, connu sous le nom de focus, un groupe d'apparence partagée a un point de contrôle unique de la ressource partagée d'apparence. Ceci est défini comme un agent d'apparence pour un groupe. Bien qu'un agent d'apparence puisse faire partie d'un serveur centralisé, il pourrait également coexister dans un UA membre qui a assumé cette fonctionnalité pour un groupe. L'agent d'apparence connaît ou est capable de déterminer l'état du dialogue de tous les membres du groupe.

Bien que la ressource d'apparence puisse être gérée de manière coopérative par un groupe d'UA sans aucun contrôle central, cela est en dehors de la portée de ce document. Il est également possible que la logique de l'agent d'apparence puisse être distribuée dans tous les UA du groupe. Par exemple, les règles qui régissent l'attribution de numéros d'apparence pour les demandes entrantes (par exemple, le numéro d'apparence disponible le plus bas) et les règles de gestion des conflits (par exemple, lorsque deux UA demandent l'utilisation du même numéro d'apparence, hacher les identifiants de dialogue et comparer avec le hachage le plus bas gagnant) devraient être définies et mises en œuvre.

Pour mieux satisfaire REQ-9, le numéro d'apparence d'un INVITE entrant doit être contenu dans l'INVITE, en plus d'être livré dans le NOTIFY du package de dialogue. Sinon, si le NOTIFY est retardé ou perdu, un UA du groupe pourrait recevoir un INVITE entrant mais pourrait ne pas savoir quel numéro d'apparence rendre pendant l'alerte.

Cette spécification définit un paramètre d'extension, qui est défini de manière normative dans la section 7, pour le champ d'en-tête Alert-Info dans RFC 3261 pour transporter le numéro d'apparence:

Alert-Info: <urn:alert:service:normal>;appearance=1

La liste suivante décrit le fonctionnement de la fonctionnalité d'apparences partagées.

1. Un UA est configuré avec l'AOR d'un groupe d'apparence partagée. Il s'enregistre auprès de l'AOR, puis tente un abonnement à l'état du dialogue à l'AOR. Si l'abonnement échoue, boucle sur lui-même ou renvoie une erreur, il sait qu'il n'y a pas d'agent d'état et, par conséquent, pas d'agent d'apparence et que cette fonctionnalité n'est pas implémentée.

2. Si l'abonnement reçoit un 200 OK, l'UA sait qu'il existe un agent d'état et que la fonctionnalité est implémentée. L'UA suit ensuite les étapes de cette liste.

3. Les informations apprises sur l'état du dialogue d'autres UA dans le groupe sont rendues à l'utilisateur.

4. Les appels entrants sont bifurqués vers tous les UA du groupe, et n'importe lequel peut répondre. Les UA reçoivent le numéro d'apparence à utiliser pour rendre l'appel entrant dans un NOTIFY de l'agent d'apparence et dans l'INVITE lui-même. L'UA recevra également une notification si l'appel est répondu par un autre UA du groupe afin que cette information puisse être rendue à l'utilisateur.

5. Pour les appels sortants, le fonctionnement dépend de l'implémentation. Si l'utilisateur saisit un numéro d'apparence particulier pour l'appel, l'UA publie les informations de dialogue d'état en cours avec le numéro d'apparence souhaité et attend une réponse 2xx avant d'envoyer l'INVITE.

6. Pour les appels sortants, si l'utilisateur ne saisit pas d'apparence particulière ou s'en fiche, l'INVITE peut être envoyé immédiatement, et le numéro d'apparence appris au fur et à mesure que l'appel progresse à partir d'une notification de l'agent d'apparence.

7. Pour les appels sortants, si l'utilisateur ne souhaite pas qu'un numéro d'apparence soit attribué (comme lors d'un appel de consultation ou si un UA récupère un "média de service" tel que de la musique en attente [RFC7088]), l'UA publie également avant d'envoyer l'INVITE mais n'inclut pas de numéro d'apparence dans la publication.

8. Les appels établis au sein du groupe peuvent être rejoints (pontés) ou pris par un autre UA. Les informations dans les notifications du package de dialogue peuvent être utilisées pour construire des champs d'en-tête Join ou Replaces. Étant donné que le même numéro d'apparence est utilisé pour ces types d'opérations, cette information est publiée avant d'envoyer l'INVITE Join ou l'INVITE Replaces.

9. L'agent d'apparence peut ne pas avoir un accès direct à l'état de dialogue complet de certains ou de tous les UA du groupe. Si tel est le cas, l'agent d'apparence s'abonnera à l'état de dialogue des UA individuels dans le groupe pour obtenir ces informations. Dans tous les cas, l'agent d'apparence enverra des notifications normales (via les abonnements établis par les UA à l'étape 1) chaque fois que l'état de dialogue agrégé de l'AOR change, y compris lorsque des appels sont passés, répondus, mis en attente et hors attente, et raccroché.