7. Définition du paramètre d'apparence Alert-Info
Cette spécification étend [RFC3261] pour ajouter un paramètre 'appearance' au champ d'en-tête Alert-Info et également pour permettre aux proxies de modifier ou de supprimer le champ d'en-tête Alert-Info.
Les modifications apportées à l'ABNF [RFC5234] dans la RFC 3261 sont:
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI
(generic-param / appearance-param) )
appearance-param = "appearance" EQUAL 1*DIGIT
Un proxy insérant un paramètre Alert-Info 'appearance' suit les politiques Alert-Info normales. Pour indiquer le numéro d'apparence pour ce dialogue, le proxy ajoute le champ d'en-tête Alert-Info avec le paramètre 'appearance' à l'INVITE. Si un Alert-Info est déjà présent, le proxy ajoute le paramètre 'appearance' au champ d'en-tête Alert-Info. Si un paramètre de numéro d'apparence est déjà présent (associé à un autre AOR ou par erreur), la valeur est réécrite en ajoutant le nouveau numéro d'apparence. Il NE DOIT PAS y avoir plus d'un paramètre d'apparence dans un champ d'en-tête Alert-Info.
Si aucune sonnerie spéciale n'est souhaitée, une sonnerie normale DEVRAIT être indiquée en utilisant le urn:alert:service:normal dans Alert-Info, conformément à [RFC7462]. Le numéro d'apparence présent dans un champ d'en-tête Alert-Info DEVRAIT être rendu par l'UA à l'utilisateur, en suivant les directives de la section 5.3. Si l'INVITE est transféré à un autre AOR, le paramètre d'apparence dans Alert-Info DEVRAIT être supprimé avant le transfert en dehors du groupe.
La détermination de la valeur à utiliser dans le paramètre d'apparence peut être effectuée au niveau du proxy qui bifurque la requête entrante vers tous les UA enregistrés.
Il existe diverses façons pour le proxy de déterminer quelle valeur il doit utiliser pour remplir ce paramètre. Par exemple, le proxy pourrait récupérer ces informations en initiant une requête SUBSCRIBE avec Expires: 0 à l'agent d'apparence pour l'AOR afin de récupérer la liste des lignes en cours d'utilisation. Alternativement, il pourrait agir comme un UA faisant partie du groupe d'apparence partagée et SUBSCRIBE à l'agent d'état comme tout autre UA. Cela garantirait que les informations de dialogue actives sont disponibles sans avoir à interroger sur une base de besoin. Il pourrait suivre la liste des appels actifs pour l'AOR d'apparence en fonction du nombre de requêtes INVITE uniques qu'il a bifurquées vers ou reçues de l'AOR d'apparence. Une autre approche serait pour le proxy d'envoyer d'abord l'INVITE entrant à l'agent d'apparence, qui redirigerait vers l'URI du groupe d'apparence partagée et échapperait le champ d'en-tête Alert-Info approprié pour que le proxy récurse et distribue aux autres UA du groupe.
L'agent d'apparence doit connaître toutes les requêtes entrantes vers l'AOR afin de saisir le numéro d'apparence. Une façon dont cela pourrait être fait est que l'agent d'apparence s'enregistre auprès de l'AOR avec une valeur q plus élevée. Cela entraînera l'envoi de l'INVITE d'abord à l'agent d'apparence, puis son offre aux UA du groupe.