5. Description normative

Cette section décrit de manière normative les extensions de fonctionnalités d'apparences partagées. Les définitions suivantes sont utilisées tout au long de ce document:

Appearance number (Numéro d'apparence): Un numéro d'apparence est un entier positif associé à un ou plusieurs dialogues d'un AOR. Les numéros d'apparence sont gérés par un Appearance Agent et affichés et rendus à l'utilisateur par les UAs qui supportent cette spécification.

Seizing (Saisie): Une apparence peut être réservée avant qu'un appel ne soit placé en saisissant l'apparence. Une apparence peut être saisie en communiquant un état artificiel de "trying" avant d'initier réellement un dialogue.

Selecting (Sélection) (ou Not-Seizing): Une apparence est simplement sélectionnée (c'est-à-dire, non saisie) s'il n'y a pas une telle communication d'état artificiel de "trying" avant l'initiation d'un dialogue.

5.1. Éléments

Un système complet pour implémenter cette fonctionnalité consiste en:

1. Des UAs qui supportent les publications, abonnements et notifications pour le package d'événements de dialogue SIP et les extensions et comportements du package de dialogue d'apparence partagée.

2. Un Appearance Agent consistant en un State Agent pour le package d'événements de dialogue qui implémente un Event State Compositor (ESC) et les extensions et comportements du package de dialogue d'apparence partagée.

3. Un serveur proxy de forking qui peut communiquer avec le State Agent.

4. Un registrar qui supporte le package d'événements d'enregistrement.

Le comportement de ces éléments est décrit de manière normative dans les sections suivantes après les définitions des extensions du package de dialogue.

5.2. Extensions du paquet de dialogue à apparence partagée

Cette spécification définit quatre nouveaux éléments comme extensions du paquet d'événements de dialogue SIP [RFC4235]. Le schéma est défini à la section 6. Les éléments sont <appearance>, <exclusive>, <joined-dialog> et <replaced-dialog>, qui sont des sous-éléments de l'élément <dialog>.

5.2.1. L'élément <appearance>

L'élément <appearance>, enfant de l'élément <dialog>, sert à transmettre le numéro d'apparence du dialogue décrit par l'élément <dialog> parent. Lorsqu'il est envoyé par un UA dans un PUBLISH dont le parent <dialog> a l'attribut state "trying" vers l'agent d'apparence, l'UA demande l'attribution du numéro d'apparence donné au dialogue actuel ou futur ayant les identifiants de dialogue donnés. Lorsqu'un élément <appearance> est envoyé par l'agent d'apparence dans un NOTIFY, cela indique que le numéro d'apparence a été attribué au dialogue spécifié.

Notez qu'un élément <dialog-info> décrit les dialogues contenus du point de vue de l'UA (nommé par l'attribut "entity"), que la requête contenante soit envoyée par l'UA ou par l'agent d'apparence. En particulier, si l'UA a envoyé une requête dans le dialogue décrit, l'URI du champ d'en-tête To correspondrait à la valeur <remote> <identity> et le paramètre to-tag correspondrait à l'attribut remote-tag. De même, l'URI du champ d'en-tête From correspondrait à la valeur <local> <identity> et le paramètre from-tag correspondrait à l'attribut local-tag.

5.2.2. L'élément <exclusive>

L'élément <exclusive>, enfant de l'élément <dialog>, est un booléen qui, lorsqu'il vaut true, indique que l'UA n'est pas disposé à accepter un INVITE avec un champ d'en-tête Join ou Replaces ciblant le dialogue décrit par l'élément <dialog> parent de l'élément <exclusive>. Par exemple, certains systèmes d'apparence partagée n'autorisent la reprise d'appel que lorsque l'appel est en attente. Dans ce cas, l'élément <exclusive> devrait être défini à "false" lorsque l'appel est en attente et à "true" lorsqu'il ne l'est pas, plutôt que de laisser l'état d'attente impliquer la valeur "exclusive".

Il est important de noter que cet élément n'est qu'une indication. Afin d'empêcher un autre UA de prendre ou de rejoindre un appel, un UA peut, en plus de définir la balise <exclusive>, ne pas rapporter les informations complètes de dialogue à l'agent d'apparence. L'absence des informations complètes de dialogue (Call-ID, remote-tag et local-tag) empêche un autre UA de construire un champ d'en-tête Join ou Replaces. Bien qu'un UA puisse définir <exclusive> à "true", l'UA doit toujours être prêt à rejeter un INVITE Join relatif à ce dialogue. Si ces identifiants de dialogue ont déjà été partagés avec l'agent d'apparence, l'UA pourrait envoyer un INVITE Replaces pour les modifier, puis ne pas rapporter les nouveaux à l'agent d'apparence.

Si le proxy sait quels dialogues sont marqués exclusifs, le proxy PEUT imposer cette exclusivité en rejetant les requêtes INVITE Join et INVITE Replaces contenant ces identifiants de dialogue avec une réponse 403 (Forbidden).

Notez que l'exclusivité n'a rien à voir avec la sélection ou la saisie du numéro d'apparence -- elle concerne plutôt les opérations de contrôle d'appel qui peuvent être effectuées sur un dialogue.

Si l'élément <exclusive> n'est pas présent, il est supposé être false.

5.2.3. L'élément <joined-dialog>

L'élément <joined-dialog>, enfant de l'élément <dialog>, sert à transmettre les identifiants de tout autre dialogue joint (mixé ou ponté) au dialogue. Seul l'UA qui est l'extrémité commune des dialogues mixés (et qui contrôle donc l'opération de mixage) devrait inclure cet élément dans les publications vers l'agent d'apparence. Notez que cet élément devrait toujours être utilisé même lorsque le champ d'en-tête Join n'a pas été utilisé pour joindre les dialogues. Par exemple, deux dialogues distincts sur un UA pourraient être joints sans aucune opération de contrôle d'appel SIP. Les dialogues joints partageront le même numéro d'apparence.

Si l'élément <joined-dialog> n'est pas présent, on suppose que le dialogue n'est pas joint et ne sera pas joint à un autre dialogue.

5.2.4. L'élément <replaced-dialog>

L'élément <replaced-dialog>, enfant de l'élément <dialog>, sert à transmettre les identifiants de tout autre dialogue qui sera ou a été remplacé par ce dialogue. Par exemple, un UA du groupe qui reprend un appel sur un autre UA en envoyant un INVITE avec Replaces inclurait cet élément pour le dialogue remplaçant. Les dialogues remplacés partageront le même numéro d'apparence.

Si l'élément <replaced-dialog> n'est pas présent, on suppose que le dialogue n'a remplacé et ne remplacera aucun autre dialogue.

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.

5.3.1. Numéros d'apparence et contexte d'appel

Il existe des cas où deux dialogues distincts sur un UA ne sont pas mélangés mais partagent le même "contexte". C'est-à-dire qu'ils sont liés les uns aux autres et ne doivent pas être traités de la même manière que deux autres dialogues du groupe. Un exemple de ceci est un "appel de consultation" où un utilisateur met un dialogue existant en attente, puis appelle un autre utilisateur, avant de revenir au dialogue original. Un autre cas, décrit ci-dessous, se produit lors des opérations de transfert, où pendant une période transitoire, un UA est impliqué dans des dialogues avec deux autres UA, mais les dialogues sont liés et ne doivent pas être traités comme des dialogues indépendants. Ces cas sont mieux traités en n'attribuant pas de numéro d'apparence à un dialogue nouvellement créé lorsqu'il partage un contexte avec un dialogue existant. Mais si le dialogue préexistant est terminé, son numéro d'apparence doit être réattribué au dialogue nouvellement créé.

Un UA qui souhaite passer un appel mais n'a pas de numéro d'apparence attribué envoie un PUBLISH avant d'envoyer l'INVITE. Le PUBLISH n'a pas d'élément 'appearance' présent, mais il a le paramètre de champ d'en-tête Event 'shared' présent. Si la politique de l'agent d'apparence n'autorise pas les appels sans numéro d'apparence attribué, une réponse 400 (Bad Request) est envoyée par l'agent d'apparence et l'UA republiera soit en sélectionnant/saisissant un numéro d'apparence, soit en envoyant l'INVITE sans publier, auquel cas l'agent d'apparence en attribuera un.

Notez que si un agent d'apparence rejette les appels sans numéro d'apparence, certaines opérations telles que les appels de consultation, le transfert et la musique en attente peuvent être négativement impactées.

5.3.2. Numéros d'apparence et contrôle d'appel

Lorsqu'un INVITE est généré pour tenter de ponter ou de prendre un appel (c'est-à-dire contient Join ou Replaces avec un identifiant de dialogue d'un autre dialogue dans le groupe d'apparence partagée), l'UA DOIT d'abord envoyer un PUBLISH à l'agent d'apparence. Ce PUBLISH contiendra:

1. Le numéro d'apparence de l'appel rejoint ou remplacé dans l'élément <appearance>

2. Les informations de dialogue du champ d'en-tête Join dans l'élément <joined-dialog>, si le dialogue est rejoint

3. Les informations de dialogue du champ d'en-tête Replaces dans l'élément <replaced-dialog>, si le dialogue est remplacé

Notez que ces informations sont fournies à l'agent d'apparence afin qu'il puisse fournir un comportement d'attribution d'apparence approprié. Si l'INVITE Join ou Replaces a été envoyé sans publier d'abord, l'agent d'apparence pourrait attribuer un nouveau numéro d'apparence à cet INVITE, ce qui serait une erreur. Avec Join, la publication a l'élément <joined-dialog> pour empêcher l'agent d'apparence de générer une réponse 400 (Bad Request) en raison de la réutilisation d'un numéro d'apparence. Pour Replaces, le but du <replaced-dialog> est d'empêcher une condition de course où le BYE pourrait entraîner la libération du numéro d'apparence alors qu'il devrait rester avec le dialogue de remplacement.

5.3.3. Numéros d'apparence et transfert

Lors d'une opération de transfert, il est important que le numéro d'apparence ne change pas pendant l'opération. Considérez l'exemple d'Alice, membre d'un groupe d'apparence partagée, qui parle à Carol, qui est en dehors du groupe d'apparence partagée. Carol transfère Alice à David, qui est également en dehors du groupe d'apparence partagée. Par exemple, si Alice utilise l'apparence 3 pour la session avec Carol, la session résultante avec David devrait également utiliser le numéro d'apparence 3. Sinon, un changement de numéro d'apparence peut provoquer un "saut" sur l'interface utilisateur et une confusion pour l'utilisateur. Il existe deux scénarios possibles en utilisant la terminologie de la RFC 5589: Alice est le transféré dans tout type de transfert (reçoit le REFER) ou la cible de transfert dans un transfert assisté (reçoit l'INVITE avec Replaces).

Si Alice est le transféré, l'INVITE déclenché par le REFER est traité comme un appel de consultation. Alice DEVRAIT publier en demandant que l'agent d'apparence n'attribue pas de numéro d'apparence pour cet INVITE. Lorsque le transfert est terminé, Alice DEVRAIT publier à nouveau pour déplacer le numéro d'apparence du dialogue avec Carol vers le dialogue avec David. Si un PUBLISH est envoyé pour déplacer le numéro d'apparence, la publication DOIT être envoyée avant d'envoyer le BYE à Carol pour éviter une condition de course où l'agent d'apparence réattribue le numéro d'apparence après avoir vu le BYE.

Si Alice est la cible, l'INVITE entrant contiendra un champ d'en-tête Replaces. En conséquence, l'agent d'apparence aura réutilisé le numéro d'apparence du dialogue avec Carol, et ce numéro d'apparence continuera à être utilisé après que le dialogue avec Carol ait été terminé.

5.4. Agent d'apparence

Un agent d'apparence défini dans cette spécification DOIT implémenter un agent d'état de paquet de dialogue pour les UA enregistrés auprès de l'AOR. L'agent d'apparence DOIT prendre en charge les extensions du paquet de dialogue d'apparence définies à la section 5.2 et utiliser le paramètre 'shared' du champ d'en-tête Event. L'agent d'apparence DOIT prendre en charge les publications et les abonnements pour ce paquet d'événements.

L'agent d'apparence DOIT disposer d'un moyen de découvrir l'état de tous les dialogues associés à l'AOR. Si cette information n'est pas disponible auprès d'un proxy avec état d'appel ou d'un Back-to-Back User Agent (B2BUA), l'agent d'apparence peut utiliser le paquet d'événements d'enregistrement [RFC3680] pour découvrir les UA associés à l'AOR et s'abonner à leur état d'événement de dialogue. Un agent d'apparence peut également s'abonner à l'état d'événement de dialogue d'un UA afin de reconstruire l'état. Par conséquent, le registraire DOIT prendre en charge le paquet d'événements d'enregistrement.

Les notifications de paquet de dialogue sont recommandées par la RFC 4235 pour "ne contenir que des informations sur les dialogues dont l'état ou les informations de participation ont changé". Cette spécification étend la RFC 4235 comme suit. L'agent d'apparence DEVRAIT envoyer des notifications d'état d'événement de dialogue chaque fois que les événements suivants se produisent pour les UA du groupe AOR:

1. Un appel est reçu, passé, répondu ou terminé.

2. Un appel est mis en attente ou repris.

3. Un appel est joint ou remplacé.

4. Un numéro d'apparence est réservé ou libéré.

L'agent d'apparence DOIT attribuer un numéro d'apparence à tous les appels entrants et envoyer des notifications immédiates aux UA abonnés à l'AOR du groupe partagé. Un nouveau numéro d'apparence est attribué, sauf pour un INVITE entrant comportant un champ d'en-tête Join ou Replaces. Dans ce cas, le numéro d'apparence devrait correspondre au numéro d'apparence du dialogue joint ou remplacé. Si l'INVITE Replaces ou Join provient de l'extérieur du groupe d'apparence partagée, l'agent d'apparence inclura un élément <joined-dialog> ou <replaced-dialog> dans le NOTIFY, contenant les informations de dialogue du champ d'en-tête Replaces ou Joined.

L'agent d'apparence DOIT pouvoir communiquer avec le proxy de bifurcation pour découvrir les appels entrants et également transmettre le numéro d'apparence au proxy, ou garantir que le champ d'en-tête Alert-Info est inclus dans l'INVITE avec le numéro d'apparence approprié.

Notez que les UA doivent pouvoir traiter des INVITE entrants sans numéro d'apparence attribué. Cela pourrait être dû à une défaillance de l'agent d'apparence ou à une autre condition d'erreur. Bien que le rendu correct de l'INVITE puisse être impossible, cela vaut mieux que d'ignorer l'INVITE ou de le faire échouer.

Un agent d'apparence DEVRAIT attribuer un numéro d'apparence à un dialogue sortant si aucun PUBLISH n'a été reçu pour sélectionner/saisir un numéro d'apparence particulier.

Notez que si le groupe d'apparence partagée comporte des UA non conscients des apparences qui passent des appels, l'agent d'apparence attribuera tout de même des numéros d'apparence pour les INVITE envoyés par ces UA.

Un agent d'apparence recevant un PUBLISH avec un numéro d'apparence vérifie que la publication est valide. Un numéro d'apparence ne peut être attribué qu'à un seul dialogue, sauf s'il existe un élément <joined-dialog> ou <replaced-dialog> indiquant que le dialogue sera/a été remplacé ou joint. Une réponse 400 (Bad Request) est renvoyée si le numéro d'apparence choisi est invalide, et un NOTIFY immédiat DEVRAIT être envoyé à l'UA contenant l'état complet des événements de dialogue.

Un agent d'apparence recevant un PUBLISH sans numéro d'apparence mais avec le paramètre 'shared' du champ d'en-tête Event présent l'interprète comme une demande de l'UA de ne pas attribuer de numéro d'apparence. Si la politique de l'agent d'apparence ne le permet pas, une réponse 400 (Bad Request) est renvoyée. Si la politique le permet, une réponse 200 (OK) est renvoyée et aucun numéro d'apparence n'est attribué. Un agent d'apparence n'a pas à partager ces informations de dialogue (c'est-à-dire à envoyer un NOTIFY) avec les autres UA du groupe, car les informations ne seront pas affichées par les autres UA.

L'agent d'apparence attribue un numéro d'apparence à un dialogue depuis le moment où l'apparence est demandée via un PUBLISH ou depuis la réception d'un INVITE jusqu'au moment où le dernier dialogue associé à l'apparence est terminé, y compris tous les dialogues qui sont joints ou remplacés. Pendant l'état de dialogue précoce, l'agent d'apparence contrôle le rythme de publication de l'état de dialogue à l'aide du champ d'en-tête Expires dans les réponses 200 (OK) aux requêtes PUBLISH. Un intervalle de 3 minutes est RECOMMANDÉ. Une fois le dialogue associé à la publication confirmé, l'expiration de l'état de publication n'a aucun effet sur l'attribution de l'apparence. Si la publication ne contient aucune information d'état de dialogue, l'agent d'apparence DOIT réserver le numéro d'apparence pour l'UA mais ne peut pas attribuer l'apparence à un dialogue particulier de l'UA. Lorsque l'état de publication est mis à jour avec des informations de dialogue, le numéro d'apparence peut alors être attribué au dialogue particulier. Un UA auquel un numéro d'apparence a été attribué à l'aide d'un PUBLISH PEUT libérer le numéro d'apparence en supprimant l'état d'événement au moyen d'un PUBLISH, comme décrit dans [RFC3903].

Si un INVITE est envoyé par un membre du groupe vers l'AOR partagé (c'est-à-dire qu'il appelle son propre AOR), l'agent d'apparence DOIT attribuer deux numéros d'apparence. Le premier numéro d'apparence sera celui sélectionné ou attribué à l'INVITE sortant. Le second numéro d'apparence sera un autre numéro attribué par l'agent d'apparence pour l'INVITE lorsqu'il est bifurqué vers les membres du groupe.

Cela vise à préserver un comportement courant dans les systèmes hérités.

Si un INVITE est envoyé par un membre du groupe en utilisant l'AOR partagé ou envoyé vers l'AOR partagé et qu'aucun numéro d'apparence n'est disponible, le proxy PEUT rejeter l'INVITE avec un code de réponse 403 (Forbidden).

Les numéros d'apparence ne sont utilisés que pour les dialogues auxquels un ou plusieurs UA associés à l'AOR du groupe participent. Si un INVITE entrant vers l'AOR du groupe est transféré vers un autre AOR, le numéro d'apparence est immédiatement libéré et peut être attribué à un autre dialogue.