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.