Résumé

  • Le triplet Call-ID, to-tag, from-tag de Replaces désigne un seul dialogue SIP créé par INVITE. Un appariement exact ne dispense jamais le terminal destinataire d’authentifier puis d’autoriser l’initiateur.
  • La protection de la continuité repose sur un ordre strict : accepter le nouvel INVITE, puis seulement envoyer BYE ou CANCEL sur l’ancien dialogue. En cas d’échec de média, de chiffrement, de QoS ou de ressources, l’ancien dialogue doit rester intact.
  • REFER, Referred-By, Target-Dialog, la réponse 2xx au nouvel INVITE et la fin effective de l’ancien leg sont des preuves différentes. Une plateforme qui les fusionne s’attribue une autorité que le protocole conserve au niveau local.

Un transfert n’est pas un paquet, mais une chaîne de décisions

Prenons un transfert supervisé. Un conseiller parle avec un client et ouvre en parallèle une consultation avec une experte. Il envoie ensuite au terminal du client une requête REFER dont la cible contient les informations nécessaires pour remplacer le dialogue de consultation. Le terminal du client accepte la requête.

Cette acceptation ne dit pas encore que l’experte recevra le client. Le terminal doit produire un nouvel INVITE. Cet INVITE doit atteindre la bonne instance. Son champ Replaces doit identifier exactement le dialogue de consultation. L’experte doit reconnaître l’initiateur comme autorisé. Enfin, son terminal doit pouvoir admettre la nouvelle session avec ses médias, ses clés et ses ressources.

Si la dernière étape échoue, l’ancien dialogue doit survivre. Si l’autorisation échoue, il n’a jamais été question de le supprimer. Si le triplet ne correspond à rien, il n’existe même pas de cible sur laquelle exercer une autorité.

RFC 3891 rend cette chaîne explicite. Le champ Replaces coordonne une intention précise : remplacer logiquement un dialogue existant par celui que crée le nouvel INVITE. Il ne transforme ni le référent, ni le proxy, ni le détenteur des identifiants en propriétaire de la conversation.

Un nouveau Call-ID pour préserver une nouvelle décision

Le mécanisme ne modifie pas l’ancien dialogue sur place. Replaces apparaît dans un nouvel INVITE doté de son propre Call-ID. Ce choix évite que des terminaux infèrent une association à partir de champs ordinaires ou qu’une extension inconnue altère silencieusement une session en cours.

L’INVITE conserve toutes ses fonctions normales : demande d’admission, négociation de session, authentification, contrôle des ressources et réponse. Replaces ajoute une intention de contrôle d’appel visible. Le terminal peut annoncer son support avec Supported: replaces; l’émetteur peut employer Require: replaces s’il veut un échec explicite chez un pair qui ne comprend pas l’extension. Le registre IANA des paramètres SIP répertorie toujours le champ et l’option tag.

Cette signalisation de capacité n’est pas une autorisation anticipée. Elle signifie « je comprends cette primitive », pas « j’accepte tout remplacement présenté par tout utilisateur ».

Replaces n’est pas non plus un autre nom pour REFER. REFER demande à son destinataire de contacter une ressource. Replaces indique quel dialogue local le nouvel INVITE veut remplacer. L’un peut exister sans l’autre. Leur association fréquente dans le transfert ne justifie pas de leur attribuer un état commun.

Le piège de la perspective des tags

Le champ contient un Call-ID ainsi qu’exactement un to-tag et un from-tag. Le UAS qui reçoit le nouvel INVITE compare to-tag à son tag local et from-tag à son tag distant.

Cette perspective est plus importante que l’ordre visuel To/From dans une ancienne trace. Un opérateur peut recopier les bons octets dans le mauvais sens. Une implémentation peut reconstruire le mauvais point de vue après un basculement. Le résultat sera 481 ou un état interne incohérent, alors même que le dialogue recherché a bien existé.

Le registre des errata de RFC 3891 illustre précisément ce risque. Un erratum éditorial vérifié corrige l’inversion des tags dans l’exemple d’un early dialog. Une autre correction éditoriale a le statut Held for Document Update. Ces corrections ne changent pas la règle normative ; elles rappellent qu’un exemple ne remplace pas le raisonnement local/distant.

Le triplet ne représente qu’un dialogue. RFC 3891 exclut l’appariement de plusieurs dialogues, d’un appel entier, d’une transaction entière ou d’un arbre complet de forking. Un INVITE initial peut ouvrir plusieurs branches précoces. Replacer l’une d’elles ne ferme pas les autres. Une redirection du nouvel INVITE vers d’autres Contacts ne reproduit pas le routage du premier appel : l’appariement échoue.

À l’inverse, un système métier qualifie souvent d’« appel » un ensemble bien plus large : leg client, leg agent, consultation, enregistrement, file, facturation. Toute projection du résultat d’un dialogue sur cet ensemble exige une règle explicite et auditable.

Identifier l’objet ne choisit pas l’action

Avant l’appariement, le UAS valide la requête. Plusieurs champs Replaces, Replaces dans une méthode autre qu’INVITE, ou des instructions de contrôle contradictoires conduisent à 400.

Le contraste avec RFC 3911 est instructif. Le champ Join emploie lui aussi un Call-ID et deux tags pour trouver un dialogue. Mais il propose d’ajouter le nouveau dialogue à l’espace de conversation. Replaces propose de supprimer le dialogue ciblé et de lui substituer le nouveau. Les deux dans un même INVITE sont contradictoires.

Les identifiants répondent donc à « quoi ? ». Le nom du champ répond à « quelle opération ? ». L’authentification répond à « qui ? ». L’autorisation répond à « a-t-il le droit ? ». L’admission répond à « est-ce possible maintenant ? ». Les événements suivants répondent à « qu’est-il réellement arrivé ? ».

Si Replaces correspond à plusieurs dialogues, le UA doit agir comme si aucun ne correspondait. L’absence de correspondance, ou la correspondance avec un dialogue qui n’a pas été créé par INVITE, donne 481. Un dialogue déjà terminé doit normalement conduire à 603, afin qu’une demande tardive ne soit pas présentée à l’utilisateur comme un nouvel appel ordinaire.

Un 481 n’est pas une preuve de fraude. Il peut révéler des tags inversés, une cible périmée, un mauvais terminal, une perte d’état après failover, un retargeting ou une course avec la fin normale du dialogue. L’observabilité doit conserver le motif technique exact.

Le point de décision reste dans le terminal destinataire

Lorsqu’un dialogue actif correspond, RFC 3891 impose au UA de vérifier que l’initiateur du nouvel INVITE est autorisé à le remplacer. L’appariement ne remplit pas cette fonction.

Le texte donne plusieurs bases possibles. Une identité authentifiée comme équivalente à l’utilisateur remplacé peut être admise ; un Referred-By lié à une requête REFER peut indiquer que l’autre participant a déclenché l’action ; une politique locale peut accepter d’autres relations. La politique appliquée au nouveau dialogue peut différer de celle qui régissait l’ancien.

Ces exemples n’accordent pas de mandat général. Des credentials partagés peuvent représenter plusieurs terminaux d’une même identité ou une délégation légitime. Mal délimités, ils donnent à un compte de service le pouvoir de remplacer les appels d’autres utilisateurs ou d’autres tenants. L’authentification prouve la maîtrise d’un credential, non le consentement présent d’une personne, ni sa qualité juridique, ni son pouvoir contractuel.

RFC 3892 traite Referred-By avec la même prudence. Le referee transporte l’information du referrer vers la cible et se trouve donc en position de la lire ou de la falsifier. Une URI Referred-By non protégée peut servir d’indice ; si elle détermine l’admission ou l’information affichée à l’utilisateur, la cible devrait exiger un token valide. Sans token, le renseignement est suspect.

Un token valide protège un ensemble de déclarations — identité du referrer, Refer-To, date — sous les contrôles prévus. Il ne prouve pas automatiquement un mandat d’entreprise, le maintien d’un consentement à l’enregistrement, un droit de trading ou la transférabilité d’un service réglementé.

La connaissance d’un dialogue est une preuve conditionnelle

RFC 4538 définit Target-Dialog pour les cas où l’autorisation d’une nouvelle requête dépend du fait que son auteur connaît un dialogue existant. Si ce dialogue a été établi via SIPS, si ses identifiants sont imprévisibles et si la relation de confiance avec le chemin initial est définie, la connaissance du triplet peut étayer une décision.

La portée vient des conditions. Sur un chemin non protégé, un observateur peut avoir appris les identifiants, et le UAS n’est pas tenu d’accorder la même confiance. Même sur SIPS, le UAS peut comprendre l’extension et refuser la demande selon sa politique.

Connaître la coordonnée d’un objet est donc une preuve possible d’accès à un contexte. Ce n’est pas un titre de propriété. La méthode demandée, l’identité, le chemin, la politique et le risque subi par le terminal donnent sa valeur à cette preuve.

C’est une application concrète de la question centrale posée par Heng Lu : qui, précisément, avait le pouvoir d’autoriser la décision contraignante ? Dans Replaces, la réponse n’est pas « celui qui connaît le Call-ID ». Elle se trouve chez le UA qui détient le dialogue et doit supporter la conséquence opérationnelle.

L’autorisation ne garantit pas que le nouvel appel soit admissible

Après une autorisation favorable, le UAS tente d’accepter le nouvel INVITE, de réaffecter l’interface et les ressources de l’ancien dialogue, puis de fermer celui-ci.

L’admission peut encore échouer. RFC 3891 mentionne l’impossibilité d’obtenir la QoS ou le keying requis et l’incompatibilité des médias. Une insuffisance de ressources ou une autre condition normale d’INVITE peut produire le même résultat. Dans ce cas, le UAS doit retourner une erreur appropriée et laisser le dialogue correspondant inchangé.

Cette règle protège le dernier chemin qui fonctionne. Supprimer sur simple correspondance permettrait à des identifiants volés ou périmés de détruire un appel. Supprimer après authentification sacrifierait l’appel devant une offre incompatible pourtant présentée par un acteur légitime. Attendre l’admission du nouveau dialogue conserve une issue de repli.

Pour un dialogue confirmé, le UAS envoie d’abord un 2xx au nouvel INVITE, puis BYE sur l’ancien dialogue. Pour un early dialog qu’il a lui-même initié, il accepte le nouvel INVITE puis envoie CANCEL sur l’ancienne invitation.

Le paramètre early-only resserre encore l’intention. Si le dialogue est déjà confirmé, le résultat est 486 : une opération visant une sonnerie ne doit pas évincer une conversation qui vient d’être prise. Si l’early dialog n’a pas été initié par le UAS qui reçoit le nouvel INVITE, le résultat est 481 et l’état demeure intact.

Un 2xx au nouvel INVITE est une preuve forte d’admission. Il n’atteste pas à lui seul la livraison de BYE, la disparition d’un leg aval derrière un B2BUA, la fin des autres branches, la continuité RTP, l’enregistrement ou l’arrêt de la facturation. La suite doit être observée.

REFER conserve son propre consentement et son propre résultat

RFC 3515 demande à un UA qui reçoit un REFER bien formé d’obtenir l’approbation de l’utilisateur, par interaction ou politique configurée. Une fois cette approbation acquise, le UA contacte la ressource du Refer-To selon les règles normales de la méthode concernée.

Dans un transfert supervisé, Refer-To contient souvent une URI SIP avec un Replaces échappé. Le transferee crée le nouvel INVITE ; la transfer target effectue ensuite son propre appariement, sa propre autorisation et sa propre admission.

L’acceptation de REFER et l’issue de l’action référencée sont distinctes. Les NOTIFY rendent compte de la progression et du résultat. RFC 7647 remplace l’ancien 202 d’acceptation par 200 et clarifie l’emploi de GRUU et Target-Dialog pour éviter la réutilisation problématique de dialogues. Ce 200 ne devient pas pour autant une attestation de transfert achevé.

RFC 5589 précise qu’une transaction REFER réussie ne termine pas la session entre transferor et transferee. Une requête BYE ultérieure est nécessaire. Les scénarios d’échec — cible occupée, absence de réponse, refus du nouvel INVITE — permettent de sortir le transferee de hold et de reprendre la session connue.

Le système métier doit donc distinguer : approbation de REFER, réponse à REFER, résultat du nouvel INVITE, fermeture de l’ancien dialogue et continuité du service. Le premier succès n’est pas le cinquième.

Construire une chronologie plutôt qu’un verdict synthétique

La preuve commence par deux identités distinctes : le Call-ID du nouvel INVITE et le triplet ciblé par Replaces. Il faut conserver la perspective local/remote du destinataire, l’état early/confirmed/terminated, le Contact, la route, la branche de fork et early-only.

Vient ensuite la décision : identité authentifiée, Referred-By, validation du token, version de politique, règle utilisateur ou tenant, source de l’approbation et raison de la décision. Un booléen authorized sans provenance n’est pas auditable.

L’admission conserve le code de réponse, l’empreinte SDP, les codecs et directions, le keying, la QoS, l’instance cible et ACK. Après succès, la chronologie associe BYE ou CANCEL de l’ancien dialogue, sa réponse, ses retransmissions et le dernier média observé.

REFER rejoint cette chronologie avec son Call-ID, CSeq, Target-Dialog, l’empreinte de Refer-To, l’approbation, la réponse et chaque NOTIFY. Il ne doit pas écraser l’état du nouvel INVITE. Le résultat annoncé se confronte aux legs réels.

Il faut tester les tags inversés, les correspondances ambiguës, les dialogues terminés, la course early-only, l’absence de support Require: replaces, le refus d’autorisation après un bon match, le token Referred-By invalide, les échecs de média/keying/QoS, busy/no-answer, la perte de BYE après un 2xx, les branches résiduelles, le retargeting, la perte d’état au failover et les mappings B2BUA impossibles à reconstruire.

Un dossier de transfert défendable ne dit pas seulement « réussi ». Il montre ce qui a été demandé, quel dialogue a été nommé, qui pouvait décider, ce qui a été admis, ce qui a été fermé et ce que l’utilisateur a effectivement reçu.

Sources