5.3. Agents utilisateurs à apparence partagée

Les UA qui prennent en charge la fonctionnalité d'apparences partagées utilisent le paquet d'état de dialogue [RFC4235] avec les extensions d'apparence partagée et le paramètre de champ d'en-tête Event 'shared' défini dans la section 13.

Les UA utilisent les extensions de paquet de dialogue de la section 5.2 ainsi que SUBSCRIBE [RFC6665], NOTIFY [RFC6665] et PUBLISH [RFC3903]. Les requêtes SUBSCRIBE, NOTIFY et PUBLISH pour le paquet d'événements de dialogue incluent le paramètre de champ d'en-tête Event 'shared' comme requis par cette spécification.

La présence du paramètre de champ d'en-tête Event 'shared' indique à l'agent d'apparence que l'UA prend en charge cette spécification.

Lors de l'initialisation, l'UA DOIT s'abonner au paquet d'événements de dialogue de l'AOR et actualiser l'abonnement conformément au cadre d'événements SIP [RFC6665]. Si la requête SUBSCRIBE échoue, aucun agent d'apparence n'est peut-être présent et cette fonctionnalité n'est pas active pour cet AOR. L'UA PEUT réessayer périodiquement l'abonnement pour voir si les conditions ont changé à des intervalles d'au moins quatre heures.

Quatre heures ont été choisies pour limiter le test d'abonnement à six par jour par UA. L'augmentation de cet intervalle réduirait ce trafic d'échec mais prendrait plus de temps pour qu'un agent d'apparence nouvellement activé soit découvert.

Les UA peuvent également utiliser la présence du paramètre de champ d'en-tête Event 'shared' dans les NOTIFY pour découvrir la présence d'un agent d'apparence pour l'AOR.

Les UA qui implémentent la fonctionnalité d'apparences partagées, la prise d'appel, la jonction et le pontage DOIVENT prendre en charge l'envoi d'un INVITE avec Replaces [RFC3891] ou Join [RFC3911]. Le client d'agent utilisateur (UAC) doit inclure les informations to-tag et from-tag dans l'en-tête Replaces ou Join afin que le dialogue correct soit mis en correspondance par le serveur d'agent utilisateur (UAS) conformément aux règles des RFC 3891 et 3911.

Tous les UA qui implémentent la fonctionnalité d'apparences partagées et prennent en charge INVITE DOIVENT prendre en charge la réception d'un INVITE avec un champ d'en-tête Replaces [RFC3891] ou Join [RFC3911].

Lors de la publication ou de la notification d'informations de paquet de dialogue, un UA inclut le plus grand ensemble d'identification de dialogue disponible au moment de la publication, à l'exception qu'un UA peut omettre des informations s'il souhaite empêcher d'autres UA de rejoindre ou de prendre un appel. L'identification de dialogue comprend les URI cibles locales et distantes, call-id, to-tag et from-tag. Bien que ces informations d'identification de dialogue soient facultatives dans [RFC4235], elles sont essentielles dans la fonctionnalité d'apparences partagées, permettant des opérations de contrôle d'appel. Lors de la mise en attente d'appels, utilisez la balise de fonctionnalité "+sip.rendering=no" pour indiquer cela dans les notifications de paquet de dialogue. L'utilisation de la description de session SDP complète oblige plutôt le point de terminaison à effectuer beaucoup d'analyse supplémentaire, compliquant inutilement le code et invitant les erreurs.

Le rendu précis de l'état inactif/actif/alerte/attente des autres UA du groupe est une partie importante de la fonctionnalité d'apparences partagées.

Un UA qui n'a pas besoin de saisir un numéro d'apparence particulier (ou qui s'en fiche) enverrait simplement un INVITE comme d'habitude pour passer un appel sortant.

Si l'appel est un appel d'urgence, un UA NE DOIT jamais attendre une saisie confirmée avant d'envoyer un INVITE. Au lieu de cela, l'appel d'urgence DOIT se poursuivre sans attendre la transaction PUBLISH.

Si un UA nécessite un numéro d'apparence particulier, l'UA DOIT envoyer une requête PUBLISH de paquet de dialogue et attendre une réponse 2xx avant d'envoyer l'INVITE. Cela est requis dans les situations suivantes:

1. Lorsque l'utilisateur saisit un numéro d'apparence particulier pour un appel sortant (par exemple, saisir l'apparence et décrocher, si l'interface utilisateur de l'UA utilise cette métaphore).

2. Lorsque l'utilisateur a demandé qu'un numéro d'apparence ne soit pas utilisé pour un appel sortant (c'est-à-dire pendant un appel de consultation, un appel de "média de service" tel que pour la musique en attente [RFC7088], ou pour un appel non considéré comme faisant partie du groupe d'apparence partagée).

3. Lorsque l'utilisateur a choisi de rejoindre (ou de ponter) un appel existant.

4. Lorsque l'utilisateur a choisi de remplacer (ou de prendre) un appel existant.

Notez que lorsqu'un UA saisit une apparence avant l'établissement d'un dialogue (numéros 1 et 2 dans la liste ci-dessus), toutes les informations de dialogue ne seront pas disponibles. En particulier, lorsqu'un UA publie une tentative de saisir une apparence avant de connaître l'URI de destination, des informations de dialogue minimales ou inexistantes peuvent être disponibles. Par exemple, dans certains cas, seul l'URI cible local pour l'appel sera connu: aucune information de dialogue. Si la balise From et Call-ID n'étaient pas présentes dans le PUBLISH initial, un nouveau PUBLISH DOIT être envoyé dès que ces informations sont disponibles.

La première publication amènera l'agent d'apparence à réserver le numéro d'apparence pour cet UA. Si la publication n'a pas d'identifiants de dialogue (par exemple, Call-ID ou local-tag), l'agent d'apparence ne peut pas attribuer le numéro d'apparence à un dialogue particulier de l'UA jusqu'à la deuxième publication, qui contiendra certains identifiants de dialogue.

Cet état de publication est actualisé comme décrit dans [RFC3903] pendant l'état de dialogue précoce ou l'agent d'apparence peut réattribuer le numéro d'apparence. Une fois que le dialogue est passé à l'état confirmé, aucune actualisation de publication n'est nécessaire.

Cette spécification suppose que l'agent d'apparence dispose d'autres moyens que la publication UA pour connaître l'état des dialogues UA. Dans cette spécification, PUBLISH est utilisé pour indiquer les opérations de numéro d'apparence souhaitées et prévues. Une fois qu'un dialogue passe de précoce à confirmé, ce rôle est terminé; par conséquent, aucune actualisation de publication n'est nécessaire.

Les numéros d'apparence sont une étiquette abrégée pour les dialogues actifs et en attente liés à un AOR. De nombreuses fonctionnalités et services construits à l'aide de cette extension s'appuient sur le rendu correct de ces informations à l'utilisateur humain. De plus, la nature de groupe de la fonctionnalité signifie que le rendu doit être similaire entre différents fournisseurs et différents modèles. Ne pas le faire réduira considérablement la valeur et l'utilité de ces extensions de protocole. Dans une interface utilisateur correctement conçue pour cette fonctionnalité, le numéro d'apparence de chaque dialogue actif et en attente est explicitement (c'est-à-dire par numéro d'apparence) ou implicitement (en utilisant une métaphore d'interface utilisateur qui rend la numérotation et l'ordre clairs pour l'utilisateur) rendu à l'utilisateur. L'identité d'extrémité distante de chaque dialogue (par exemple, l'identité de la partie distante) n'est pas un remplacement utile pour le numéro d'apparence. L'état de chaque apparence doit également être rendu (inactif, actif, occupé, rejoint, etc.). Les UA peuvent dire qu'un ensemble de dialogues sont joints (pontés ou mélangés) ensemble par la présence d'un ou plusieurs éléments <joined-dialog> contenant d'autres identifiants de dialogue SIP. Les numéros d'apparence des dialogues peuvent être appris par les notifications de paquet de dialogue contenant l'élément <appearance> de l'agent d'apparence ou du paramètre Alert-Info 'appearance' dans un INVITE entrant. En cas de conflit, la notification de paquet de dialogue a la priorité.

Un utilisateur peut sélectionner un numéro d'apparence mais ensuite abandonner le passage d'un appel (raccrocher). Dans ce cas, l'UA libère le numéro d'apparence en supprimant l'état d'événement avec un PUBLISH comme décrit dans [RFC3903]. Ne pas le faire nécessitera des opérations inutiles par l'agent d'apparence et mobilisera des numéros d'apparence qui pourraient autrement être utilisés par d'autres UA dans le groupe d'apparence partagée.

Un UA DEVRAIT s'inscrire auprès de l'AOR seulement s'il est probable que l'UA répondra aux appels entrants. Si l'UA va principalement surveiller l'état des appels du groupe d'apparence partagée et prendre ou rejoindre des appels, l'UA DEVRAIT uniquement s'abonner à l'AOR et ne pas s'inscrire auprès de l'AOR. Si un UA de surveillance s'inscrit plutôt que de simplement s'abonner, il génère de grandes quantités de trafic réseau inutile.

Tous les UA abonnés recevront des NOTIFY de paquet de dialogue d'état d'essai pour les INVITE entrants.

Un UA NE DOIT PAS insérer un paramètre 'appearance' dans un champ d'en-tête Alert-Info dans un INVITE ou une autre requête.

L'agent d'apparence en est seul responsable.