Résumé

  • Dans le modèle de pont de conférence de la RFC 5370, le transcodeur est un B2BUA, pas un proxy. Il termine l’échange avec l’appelant et crée une autre transaction vers l’appelé.
  • La valeur du champ From doit être reprise sous réserve des exigences de confidentialité, mais pas son paramètre tag. Une identité présentée peut donc rester stable tandis que l’identité de dialogue et l’autorité qui émet la requête changent.
  • Authentifier et autoriser l’invocateur, protéger la liste d’un destinataire et reporter un même code final sont des contrôles distincts. Aucun ne prouve à lui seul l’origine de l’échec, la qualité de la transformation ou l’accessibilité du résultat.

Une continuité visuelle, deux actes protocolaires

Le modèle paraît simple sur un schéma. A appelle T, puis T appelle B. Les médias passent par T, qui fournit la conversion nécessaire. Pourtant, le mot « passe » devient dangereux dès qu’il suggère que T se contente de relayer la requête.

La RFC 5370 dit le contraire. T se comporte comme un agent utilisateur dos à dos. L’INVITE envoyé à B appartient à une transaction différente de l’INVITE reçu de A. T fabrique aussi la description de session adaptée au service qu’il rend.

La conséquence dépasse le vocabulaire SIP. L’identité de branche, le dialogue, le contexte d’authentification et la décision d’autorisation du premier côté ne migrent pas spontanément vers le second. T crée une corrélation opérationnelle entre deux actes.

Une base qui ne garde qu’un identifiant d’appel global remplace cette corrélation par une fiction. Elle sait qu’une session a traversé T, mais elle ne peut plus expliquer quelle règle a autorisé chaque jambe ni quel acteur a produit chaque état.

Le champ From ne signait pas la seconde requête

La spécification impose à T de construire le From sortant avec la valeur du From entrant, tout en respectant les exigences de confidentialité portées par la demande initiale. Elle précise que cette reprise ne concerne pas le paramètre tag.

Cette réserve empêche de confondre deux plans. Le nom ou l’adresse présentée peut représenter A auprès de B. Le tag, lui, participe à l’identité du dialogue créé sur la nouvelle jambe. Conserver l’un et remplacer l’autre est cohérent : la représentation de l’appelant continue, la transaction non.

Il faut donc distinguer au moins quatre preuves. T peut avoir authentifié l’utilisateur qui l’invoque. Il peut l’avoir autorisé à demander une conversion. Il peut présenter une valeur de From correspondant à A. Il peut enfin fournir une assertion d’identité sur l’expéditeur d’origine.

Aucune de ces preuves ne signifie que A a émis le paquet reçu par B. L’émetteur transactionnel reste T. Une interface qui affiche seulement « appel de A » masque l’intermédiaire qui a reconstruit le message.

La confidentialité modifiait la représentation

La reprise du From est conditionnée par la confidentialité demandée en amont. Cette condition introduit une décision de politique au cœur de T.

Deux journaux peuvent alors raconter des choses différentes sans que l’un soit nécessairement faux. Le journal interne de T peut connaître l’identité authentifiée. Le message vers B peut présenter une identité limitée ou transformée conformément à la demande de confidentialité.

L’erreur serait de traiter la valeur visible en aval comme une copie complète de ce que T a reçu ou vérifié. Elle est le produit d’une règle de divulgation.

Pour rendre cette règle contrôlable, la preuve minimale doit lier l’identité authentifiée, la politique d’autorisation, la demande de confidentialité, la valeur entrante, la valeur sortante et le nouveau tag. Supprimer l’un de ces champs empêche de distinguer anonymisation légitime, mauvaise configuration et usurpation.

Le même code final ne réparait pas la rupture

Quand T reçoit une réponse finale de B, il génère une nouvelle réponse finale vers A. Cette nouvelle réponse devrait employer le même code de statut que la réponse aval.

Le mécanisme préserve une classification utile. Si B refuse, A doit généralement apprendre que l’établissement n’a pas abouti. Mais recopier 603 ne transporte pas toute la causalité de la réponse de B.

La RFC l’illustre par la perte possible du 183 Session Progress. Sans ce message provisoire, A ne sait pas si le 603 Decline signifie que T a rejeté l’INVITE entrant ou que B a rejeté l’INVITE créé par T.

Les trois chiffres sont donc une donnée de résultat, pas une preuve d’auteur. Deux organisations peuvent produire le même code selon des politiques différentes, avec des conséquences différentes pour le dépannage, la responsabilité et l’expérience utilisateur.

History-Info restaurait l’attribution

La RFC 5370 demande l’usage de History-Info entre T et A pour résoudre l’ambiguïté. Le rôle de cette information n’est pas de changer le statut final, mais de donner un chemin permettant de l’attribuer.

Cette dépendance révèle la valeur d’un événement intermédiaire. Tant que le 183 est observable, A possède un indice que T a commencé le traitement et a engagé la jambe aval. Quand cet indice disparaît, la seule réponse terminale devient insuffisante.

Une plateforme de supervision qui élimine les provisoires et l’historique pour réduire le volume peut ainsi détruire le seul élément qui séparait refus du service et refus du destinataire.

La RFC 5370 citait la RFC 4244. La RFC 7044 a ensuite révisé le cadre History-Info. Cette évolution documentaire n’autorise pas à supposer qu’un déploiement donné produit, transmet ou conserve l’historique nécessaire. Il faut le vérifier sur la trace concernée.

Une autre architecture aurait rendu l’état plus explicite

Le document examine une solution différente. T aurait pu accepter A avec 200 OK, inviter B séparément, puis laisser A s’abonner à l’état de conférence pour connaître le résultat de la seconde invitation.

Cette organisation aurait exposé deux décisions plus nettement : admission de A par T, puis admission par B. Elle aurait aussi demandé davantage de messages, davantage de logique et un délai d’établissement supérieur.

La RFC explique que cette solution n’a pas été retenue pour le service de transcodage. Le modèle sélectionné réduit la coordination visible et dépend en contrepartie d’une histoire correctement conservée.

Il ne faut pas transformer ce choix en règle universelle contre les canaux d’observation. C’est un arbitrage de conception documenté en 2008 : rapidité et simplicité ont déplacé une partie du coût vers la provenance.

Le corps multipart portait deux autorités

Pour invoquer T, A envoie un INVITE contenant une description SDP et un corps recipient-list. La liste contient l’URI de B. Ces deux parties voyagent ensemble, mais elles ne gouvernent pas la même chose.

Le SDP décrit ce que A propose sur la jambe avec T. La liste indique à T vers qui créer une nouvelle requête. Protéger la première sans protéger la seconde défendrait les paramètres média tout en laissant mutable l’autorité de destination.

La RFC limite cette liste à une seule URI pour ce modèle. Une liste plus longue devrait recevoir 488. Cette limite appartient au service de transcodage à deux parties ; elle n’annule pas les usages multiparty de la RFC 5366.

Le hash de la liste, son nombre d’entrées et l’URI effectivement appelée devraient figurer dans le reçu. Sans eux, une réussite de négociation ne prouve pas que T a contacté le destinataire autorisé.

L’exception d’opt-in avait des conditions

Les services fondés sur des listes peuvent amplifier une demande et générer des communications non sollicitées. La RFC 5370 conclut néanmoins que les transcodeurs de ce modèle n’ont pas à utiliser des listes d’adhésion préalable.

Le raisonnement est étroit. T ne génère qu’un INVITE. A fournit lui-même l’URI connue de B. L’identité de l’appelant est présente dans la requête produite par T.

L’exception ne survit pas automatiquement à une évolution du produit. Si une URI devient un groupe, si T résout un identifiant opaque vers des cibles inconnues de A, ou si l’identité est supprimée, le système n’est plus celui analysé.

Une politique devrait donc enregistrer les trois prémisses au lieu de stocker seulement « opt-in non requis ». Sinon, une décision juste à l’origine devient une permission générale après plusieurs extensions fonctionnelles.

Authentifier T ne prouvait pas son résultat

La sécurité de la RFC 5363 s’applique au service de liste. La RFC 5370 insiste sur l’intégrité de la liste et sur le risque de demandes non sollicitées. Elle demande aussi à T d’authentifier et d’autoriser ses utilisateurs.

Authentification et autorisation répondent à l’entrée : qui demande, et cette personne peut-elle demander ? Elles ne prouvent pas que T a généré le bon SDP, appelé B, produit une conversion fidèle ou limité la conservation des médias.

Les références à TLS, S/MIME et au mécanisme d’identité SIP appartiennent au contexte de publication. La RFC 4474 a depuis été remplacée par la RFC 8224, et la RFC 5246 appartient à une lignée TLS ultérieurement mise à jour. L’article ne transforme pas ces références historiques en conseil de configuration actuel.

La preuve utile doit nommer le mécanisme réellement négocié et le résultat réellement vérifié, sans déduire la sécurité moderne du simple numéro d’une référence de 2008.

Le renvoi 302 proposait une nouvelle action

La RFC décrit aussi l’invocation par l’appelé. Si B ne peut accepter la description de session, il peut renvoyer 302 Moved Temporarily. Le Contact indique l’URI de T et contient un paramètre ?body= avec une liste comprenant l’URI de B.

Ce 302 n’est pas une conversion. Il demande à A de reconnaître l’échec initial puis de créer un nouvel INVITE vers T. T devra ensuite inviter B.

Le document souligne la complexité de l’encodage d’un corps dans une URI, notamment l’échappement des retours de ligne, et juge le modèle 3pcc plus simple pour ce cas.

Dans une chaîne d’audit, il faut conserver la réponse de redirection, le Contact exact, le hash du corps décodé, la décision de A de suivre ou non, puis les deux nouvelles transactions. Déduire l’exécution à partir du seul 302 confond invitation à agir et acte accompli.

Deux jambes réussies pouvaient encore échouer pour la personne

La finalité déclarée du modèle comprend des services comme la parole vers le texte pour des personnes sourdes ou malentendantes. La signalisation peut établir A–T et T–B, et les paquets peuvent circuler sur les deux jambes.

Ces observations ne disent pas si la langue est correcte, si la latence permet une conversation, si le sens est préservé, si la direction convient ou si l’utilisateur comprend le résultat.

Une métrique « session établie » décrit l’infrastructure. Une métrique d’accessibilité doit atteindre le niveau humain et accepter l’état inconnu quand cette preuve manque.

La distinction évite une forme de blanchiment du succès : transformer deux 200 OK et un flux média en affirmation que l’obligation envers l’utilisateur a été remplie.

Le minimum utile gardait les séparations

La Minimum Initial Specification de Lu Heng sert ici de grille déclarée. Le minimum interopérable n’est pas un dossier infini. C’est un ensemble compact : invocateur authentifié, autorisation, cible unique protégée, règle de confidentialité, transaction amont, transaction aval, réponse attribuée et identité du service.

Les décisions futures peuvent rester locales si ce noyau est exporté. Chaque opérateur peut choisir sa conservation ou sa mise en œuvre sans effacer l’autorité nécessaire à une vérification ultérieure.

Reality Layers fournit la seconde grille. La valeur de From, le credential, le dialogue, le code, le flux média, la transformation et la compréhension sont des réalités différentes. Les fusionner ne crée pas de certitude ; cela rend l’incertitude invisible.

La RFC 5370 pose donc une limite nette : T est un B2BUA, pas un proxy. Après cette limite, toute continuité apparente doit être documentée comme corrélation et non supposée comme identité.