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é.