Résumé

  • RFC 5369 est un cadre informationnel, non une norme Internet, pour détecter le besoin de transcodage SIP puis invoquer un service selon un modèle 3pcc ou pont de conférence.
  • La présence ou SDP peut décrire une capacité, mais le fork parallèle peut conduire l’appel vers un autre agent utilisateur. L’offreur ne devrait pas introduire de transcodeur avant d’avoir établi l’incompatibilité du répondant effectif.
  • Le choix de topologie change les pouvoirs : 3pcc sélectionne flux et directions au prix d’une orchestration plus riche ; le pont réduit les échanges du terminal mais concentre média et signalisation. Tout transcodeur doit lire et modifier le média.

Le document de présence avait un propriétaire

Une présence n’est pas une fiche abstraite sur une personne. Elle est publiée par une source, pour une identité et un ensemble de capacités, à un instant donné.

RFC 5369 cite la présence comme un moyen par lequel un offreur peut connaître les capacités distantes. SDP peut aussi fournir cette information dans une réponse à OPTIONS ou dans un 488 à INVITE.

Ces observations ne sont pas interchangeables. La présence peut annoncer le terminal disponible avant l’appel ; SDP décrit ce qu’un agent a déclaré dans une transaction précise.

Le registre doit garder l’émetteur, le Contact, la version, la fraîcheur et la portée. Transformer « ce téléphone est audio » en « Bob est audio » efface le sujet technique et la liberté de routage.

Le fork choisissait après la prévision

Une invitation SIP peut être envoyée en parallèle à plusieurs agents. Messagerie vocale, téléphone, client logiciel et passerelle peuvent avoir des capacités différentes.

En l’absence d’une information suffisamment liée aux branches, l’appelant ne sait pas lequel répondra. RFC 5369 rattache cette difficulté au problème HERFP et ne prétend pas le résoudre.

Le prochain appel peut donc suivre une autre branche que le précédent. Une réussite passée n’est pas une preuve de la topologie future.

Le système doit distinguer l’ensemble des candidats, les réponses provisoires, la branche retenue, le dialogue final et l’offre-réponse. C’est à ce dernier ensemble que la décision de transcodage doit être attachée.

La recommandation était d’attendre la preuve

RFC 5369 recommande à l’offreur de ne pas invoquer le transcodage avant d’être sûr que le répondant ne prend pas en charge les capacités nécessaires.

Cette prudence a un mécanisme concret. Si chaque côté anticipe à tort une incompatibilité, deux transcodeurs peuvent être insérés dans une session où les terminaux partageaient déjà un codec.

Le média subit alors plus de transformations, de latence et de risques de qualité. Deux services obtiennent aussi un accès qui n’était pas nécessaire.

Une politique automatique doit demander une intersection de capacités liée au répondant choisi. Une étiquette de profil ou une statistique de parc ne suffit pas.

Le besoin ne découvrait pas le serveur

Le cadre laisse la découverte du serveur média hors périmètre. Il suppose que l’agent invoquant connaît l’URI d’un service.

La preuve du besoin n’est donc pas une preuve de destination. Il faut encore sélectionner un service capable de réaliser la transformation exacte, dans le bon sens et sous la bonne politique.

Disponibilité, juridiction, identité, capacité, langue, latence, conservation et coût appartiennent au service choisi. Aucun de ces attributs ne découle du seul échec d’intersection des codecs.

Le journal doit séparer incompatibilité observée, sélection de T, authentification, négociation des deux jambes, réception du média et résultat transformé.

L’incompatibilité pouvait appartenir à l’utilisateur

Deux terminaux peuvent ne partager aucun codec. Mais un terminal peut aussi décoder parfaitement un flux audio que son utilisateur sourd ne peut pas comprendre.

RFC 5369 applique les mêmes mécanismes d’invocation SIP à ces deux familles d’incompatibilité. Cette unité de mécanisme ne rend pas leurs preuves identiques.

Une intersection de codecs est calculable. Une préférence d’accessibilité doit préciser personne, but, langue, modalité, sens et contexte.

Le transcodage peut être symétrique, par exemple parole-texte et texte-parole, ou asymétrique. « Service actif » ne dit pas quelle direction aide effectivement l’utilisateur.

3pcc conservait la signalisation entre les extrémités

Dans le modèle de contrôle d’appel par tiers, l’agent qui invoque entretient une relation de signalisation avec T et une autre avec l’agent distant. T n’a pas de relation de signalisation avec ce dernier.

Un terminal avancé peut ainsi faire passer par T seulement les flux incompatibles. Les flux déjà compatibles restent directs.

Il peut aussi choisir un transcodeur pour l’émission et un autre pour la réception. L’autorité se distribue par flux et par direction.

RFC 5369 qualifie de élevé le niveau de confidentialité de la signalisation, car T ne voit pas les échanges entre les deux terminaux. Cela ne signifie pas que T ne voit pas le média qu’il transforme.

Le pont simplifiait un acteur précis

Le modèle de pont de conférence traite T comme un serveur de conférence à deux participants. T agit en B2BUA et négocie séparément A–T et T–B.

Le terminal invoquant effectue généralement moins d’échanges de signalisation. Cela peut aider sur un accès à faible débit ou forte latence, et permet à un terminal simple de participer.

La souplesse diminue : impossible de choisir un transcodeur distinct pour chaque flux ou chaque sens. T devient le point central de média et de signalisation.

Dire que le pont est « plus simple » doit donc nommer le bénéficiaire. La simplicité du terminal peut déplacer du travail vers le service, la sécurité et l’exploitation.

Un changement en cours de session avait un coût différent

Une session peut commencer en audio compatible puis ajouter une vidéo incompatible. Le besoin n’est pas toujours connu au départ.

Le modèle 3pcc permet d’insérer T en cours de session avec une relative simplicité. Avec un pont, l’insertion ou le remplacement exige que l’agent distant prenne en charge l’extension Replaces.

RFC 5369 observait en 2008 que peu d’agents la prenaient en charge. Cette phrase est un constat historique du document, pas une mesure actuelle.

Avant une migration, l’opérateur doit vérifier la capacité de l’agent réellement sélectionné. Le support théorique d’une gamme de produits n’est pas un reçu de ce dialogue.

Authentifier T ne rendait pas le média de bout en bout

T doit accéder au média pour le convertir. Le cadre recommande de l’authentifier afin d’éviter qu’un service malveillant ne reçoive les échanges.

L’authentification prouve une identité selon une politique. Elle ne prouve ni la minimisation des flux, ni la bonne transformation, ni l’absence de conservation.

Le chiffrement et l’intégrité ordinaires de bout en bout sont incompatibles avec une transformation qui doit lire et modifier le contenu. Les jambes A–T et T–B peuvent rester protégées séparément.

Une interface qui affiche seulement « chiffré » doit donc expliquer le point de terminaison. Deux segments protégés ne signifient pas que seul A et B ont vu le média.

Deux directions réduisaient une concentration

Avec 3pcc, un service peut traiter le sens aller et un autre le retour. Aucun transcodeur unique ne possède alors tout le média.

Cette architecture réduit une concentration, mais crée deux identités de service, deux décisions, deux politiques de conservation et un besoin de corrélation contrôlée.

Les horaires, les journaux et un opérateur commun peuvent encore relier les sens. La formule « personne ne voit tout » demande une analyse du système complet.

Le reçu doit indiquer direction, flux, T, clés de jambe, transformation, sortie et suppression, plutôt qu’un simple statut de session.

Les références de 2008 restaient historiques

RFC 5369 a été publié en octobre 2008 avec le statut Informational et dit expressément ne pas définir une norme Internet.

Il cite les documents TLS et S/MIME disponibles alors pour l’authentification. RFC 5246 a ensuite été rendu obsolète par RFC 8446 ; RFC 3850 appartient à une lignée S/MIME plus ancienne. Cet article n’en tire aucune configuration cryptographique actuelle.

RFC 3265, cité pour NOTIFY, a été remplacé par RFC 6665. L’évolution documentaire ne transforme toujours pas une capacité annoncée en propriété du répondant futur.

RFC 3351 porte les exigences d’accessibilité ; RFC 4117 et RFC 5370 décrivent les modèles d’invocation. Leur existence ne prouve pas le résultat humain d’une session.

Un chemin média n’était pas une preuve de compréhension

Il faut conserver une chaîne de reçus : capacité publiée, répondant sélectionné, incompatibilité négociée, service invoqué, deux jambes établies, média reçu, sortie produite et résultat perçu.

Chaque étape a un sujet différent. Le paquet arrivé à T ne dit pas que la transcription est intelligible ; le texte rendu ne dit pas que l’utilisateur l’a reçu à temps.

Minimum Initial Specification de Lu Heng sert ici de lentille déclarée : le contrat commun reste minimal et la décision dépend d’informations locales au terminal et à l’utilisateur. Reality Layers empêche de confondre présence, SDP, réponse, flux et compréhension. Les faits protocolaires restent ceux des RFC.