Résumé

  • Les travaux d’Eve Schooler sur MMCC puis sur le premier projet SIP ont isolé une fonction précise : localiser un destinataire, lui décrire une session et recueillir sa réponse sans transporter la session elle-même.
  • Cette séparation a rendu les communications Internet composables, tout en distribuant le pouvoir entre identité, joignabilité, négociation, transport des médias, sécurité et qualité de service.

Le projet Internet de février 1996 signé par Mark Handley et Eve Schooler ne promettait pas de bâtir une téléphonie complète. Il proposait un protocole d’invitation. L’expéditeur pouvait viser un utilisateur plutôt qu’une machine fixe ; des intermédiaires pouvaient relayer ou rediriger la demande vers sa position actuelle ; un descriptif de session indiquait les médias envisagés. Une fois l’accord obtenu, la conversation pouvait suivre sa propre route.

Cette modestie fonctionnelle était un choix. Les expériences de visioconférence sur réseaux à paquets réunissaient déjà une multitude de difficultés : participants mobiles, logiciels hétérogènes, audio et vidéo séparés, sessions multicast annoncées publiquement ou réunions privées, synchronisation et besoins de qualité variables. Les regrouper sous un seul gestionnaire aurait créé une architecture rigide. Les travaux auxquels Schooler a participé ont au contraire appris à découper le problème.

Ce que MMCC a laissé à SIP

À l’Information Sciences Institute, Schooler avait travaillé sur MMCC, un environnement de contrôle de conférences distribuées. Son curriculum vitae insiste sur l’établissement multilatéral de sessions, la propagation d’informations de qualité de service, l’hétérogénéité des configurations et la resynchronisation. Le premier projet SIP reconnaît explicitement cette filiation.

Il opère pourtant une réduction décisive. Découvrir une session annoncée et recevoir une invitation personnelle deviennent deux mécanismes différents. Le texte qualifie même la découverte de session d’orthogonale au modèle de contrôle de conférence. Après avoir trouvé l’adresse du destinataire, la requête lui transmet une description au format SDP. L’invité peut accepter, refuser ou être atteint par redirection. La disponibilité réelle des ressources réseau reste une autre question : inviter ne garantit pas la qualité de service.

En mars 1999, la RFC 2543, cosignée par Handley, Henning Schulzrinne, Schooler et Jonathan Rosenberg, définit SIP comme une signalisation de couche applicative capable de créer, modifier et terminer des sessions multimédias. La RFC 3261 qui la remplace organise cette fonction autour de la localisation, de la disponibilité et des capacités des utilisateurs, puis de l’établissement et de la gestion de session. Elle précise que SIP est un composant associé à d’autres protocoles, non un système de communication intégré de haut en bas.

Il faut préserver cette histoire collective. Schooler n’est pas l’unique inventrice de SIP et n’est pas l’autrice de la RFC 3261. Sa place est plus intéressante que ce raccourci : elle se situe dans le passage d’un gestionnaire expérimental de conférence à une fonction d’invitation que plusieurs auteurs et un groupe de travail ont rendue interopérable.

Où passe réellement l’appel

Dans un échange élémentaire, un agent SIP émet INVITE. Un service de localisation et des enregistrements relient l’adresse publique d’un utilisateur à ses contacts du moment. Des proxys acheminent la demande. Une réponse finale positive, suivie de ACK, établit le dialogue initial. Les proxys peuvent alors sortir du chemin actif de signalisation ; les paquets RTP qui transportent le son ou la vidéo prennent généralement un autre itinéraire.

SDP ne brouille pas cette frontière. Le corps d’une invitation peut décrire les types de médias, les adresses de transport et les paramètres proposés. Le modèle offre/réponse permet aux extrémités de trouver une configuration compatible. Mais un descriptif n’est pas le média qu’il décrit. SDP ne transporte rien ; RTP assure les fonctions de transport en temps réel.

On obtient ainsi non pas « un appel », mais plusieurs relations coordonnées : un chemin de signalisation vers une personne ou un domaine, une négociation sur ce que les terminaux savent échanger, puis un chemin de médias. Un nouveau INVITE au sein du dialogue peut modifier la description. L’expiration d’une invitation ne fixe pas la durée de la conversation. Les états restent liés sans être confondus.

Cette division a permis aux couches d’évoluer à des vitesses différentes. Un nouveau codec n’imposait pas de réinventer la localisation des utilisateurs. Un mécanisme de contrôle de parole ou de vote pouvait être ajouté par une application de conférence. Une réservation de ressources, lorsqu’elle était nécessaire, relevait d’un autre dispositif. SIP orchestrait une rencontre ; il ne revendiquait pas l’ensemble de ses effets.

Une séparation qui distribue le pouvoir

Ne pas transporter le média ne signifie pas être sans influence. Le service d’enregistrement décide quels contacts représentent une adresse. Un proxy applique des politiques de routage et d’admission. Un domaine peut authentifier, journaliser, refuser ou rediriger. Celui qui maîtrise ces points peut rendre une personne joignable ou invisible, même s’il n’entend jamais sa voix.

La sécurité impose la même précision. SIPS protège la signalisation sur une chaîne sécurisée vers le domaine du correspondant ; il ne chiffre pas automatiquement le flux RTP. Un indicateur de sécurité attaché à l’invitation ne prouve donc pas la confidentialité de la conversation.

Les réseaux réels réassemblent parfois ce que le protocole sépare. Les contrôleurs de frontière de session, B2BUA, relais de médias, dispositifs d’enregistrement ou services de traversée de NAT peuvent rester au milieu d’un ou des deux chemins. La RFC 7092 montre qu’un B2BUA ne se contente pas de transmettre : il termine un dialogue et en crée un autre, avec la possibilité de modifier ou d’appliquer des politiques. La frontière de SIP sert alors de grille d’analyse, pas de photographie naïve de chaque déploiement.

L’héritage de Schooler tient dans cette question opérationnelle : quelle voie est contrôlée ? Un utilisateur peut être localisé mais incapable de négocier un codec. Une session peut être signalée avec succès alors que les médias sont bloqués. La signalisation peut être authentifiée tandis que le contenu demeure exposé. En distinguant ces échecs, l’invitation qui ne portait pas la conversation a rendu l’architecture plus libre — et ses centres de pouvoir plus visibles.

Sources