Résumé

  • La RFC 3351 demandait que texte, voix, vidéo, relais et préférences puissent s’intégrer à une conversation SIP qui évolue sans être interrompue.
  • Ce document informatif formule des exigences ; il ne normalise pas une extension SIP et ne prouve pas que les services décrits aient été déployés.

La phrase la plus nette de la RFC 3351 tient en une exigence d’architecture : tout agent utilisateur participant à la conversation — y compris un service de transcodage — devrait pouvoir ajouter ou retirer un flux média sans couper puis rétablir l’appel. Une conversation vocale pourrait accueillir du texte ; un relais entrer dans l’échange, convertir un média et en ressortir. Le besoin d’un nouveau canal ne devrait pas obliger chacun à recommencer.

Publié en août 2002, le texte déplace le sujet. L’accessibilité n’y est pas seulement attachée à une catégorie d’appareil. Elle dépend de préférences qui doivent pouvoir façonner la session. La RFC définit un profil utilisateur comme un ensemble d’aptitudes et de préférences communicables par SIP, censé déterminer le traitement de la session. Le texte, l’audio et la vidéo peuvent circuler dans un sens ou dans les deux ; un flux peut passer par un service de conversion ; une passerelle peut relier un agent SIP à un ancien terminal textuel. C’est dans la session que se rencontrent ces choix.

Le statut du document interdit toutefois de confondre intention et résultat. La RFC 3351 est informative et précise qu’elle ne définit aucune norme Internet. Les verbes normatifs qu’elle emploie exposent les exigences souhaitées par ses auteurs ; ils ne font pas de la note une extension SIP normalisée. Elle ne certifie aucun logiciel et ne mesure pas le nombre de services accessibles. Ses dialogues de démonstration sont des scénarios de conception, pas des observations de déploiement.

Le profil soulève aussi une difficulté que le texte voit bien : il peut améliorer l’appel et révéler la personne. Une préférence pour le texte ou le recours à un relais peuvent dévoiler des informations sensibles. La RFC souhaite donc qu’un appelant puisse rester anonyme : son correspondant n’a pas nécessairement à apprendre qu’un relais traduit la conversation. Elle demande aux intermédiaires de publier leurs règles de confidentialité et invite les fournisseurs à ne pas rendre publiques les aptitudes et préférences lors d’une transaction.

L’accessibilité se joue autant dans ce que le service sait et conserve que dans sa capacité à transporter des mots.

La dimension économique est tout aussi explicite. Un agent utilisateur devrait pouvoir comparer les relais selon leurs capacités et leurs politiques, repérer des solutions de remplacement et connaître le prix à la minute ainsi que les frais minimums avant le début d’un appel. Dans un scénario, une émission de radio ne propose pas de texte et un prestataire refuse de convertir son flux audio, de peur d’épuiser ses ressources. La chaîne a une limite opérationnelle ; le protocole ne transforme pas cette indisponibilité en service garanti.

Les exemples vont bien au-delà d’un simple sous-titrage. Un relais peut convertir la parole en texte tout en laissant la conversation vocale ouverte, puis lire la réponse tapée à voix haute. Une conférence peut enchaîner parole-vers-texte, texte-vers-langue des signes et langue des signes-vers-texte selon les préférences des participants. Un menu téléphonique vocal peut recevoir une voie textuelle par l’intermédiaire d’un relais. Ces idées mettent le choix de la personne au centre, mais chaque conversion ajoute un prestataire, une politique, un prix éventuel et un nouvel endroit où l’information circule.

La suite des RFC est une histoire de spécifications, pas une preuve de réussite universelle. La RFC 4103 définit un format RTP pour le texte en temps réel T.140 et une redondance destinée à récupérer certains caractères perdus. La RFC 5194 établit ensuite un cadre SIP/IP plus détaillé pour le texte, la conversion, la présentation et l’interfonctionnement ; elle cite la RFC 3351 pour l’invocation des relais. La RFC 4504 recommande aux appareils téléphoniques SIP de prendre en charge ces besoins.

Plus tard, la RFC 8865 transporte le texte T.140 dans des canaux de données WebRTC fiables et ordonnés ; la RFC 9071 traite le mélange de textes multiparticipants et actualise la RFC 4103. Chaque étape précise un morceau du chemin. Aucune ne démontre que tous les terminaux, opérateurs ou services d’urgence le proposent.

La contribution historique est donc précise : changer de média ne devrait pas obliger à changer d’appel, et la personne devrait garder prise sur la manière dont ce changement se fait. Mais une session extensible peut rester hors de portée, incompatible, trop chère ou refusée par un service. Un profil utile peut en même temps dévoiler des données sensibles. Un relais peut rapprocher les médias et imposer des conditions. La RFC 3351 a fait entrer ces décisions de contrôle, de coût et de confidentialité dans la conception de l’appel ; elle n’a pas attesté que l’équilibre était atteint.

Sources : RFC 3351 · Notice RFC 3351 · Fiche Datatracker de la RFC 3351 · RFC 2119 · RFC 8174 · SIP, RFC 3261 · Modèle offre-réponse SDP, RFC 3264 · Texte conversationnel sur RTP, RFC 4103 · Cadre du texte temps réel sur SIP, RFC 5194 · Exigences des téléphones SIP, RFC 4504 · Texte T.140 sur les canaux WebRTC, RFC 8865 · Mélange RTP de texte multiparticipant, RFC 9071 · Spécification initiale minimale, décision future localisée et adoption volontaire · Primauté du code en fonctionnement