Résumé

  • Pour la RFC 3960, 180 Ringing attestait que le destinataire était alerté, non qu’une tonalité ou une annonce arrivait déjà chez l’appelant.
  • Le terminal pouvait produire une sonnerie locale en l’absence de paquets, l’interrompre quand le flux arrivait, et conserver séparés négociation, authentification, rendu et issue de l’appel.

La tonalité de retour d’appel paraît être un son venu de loin. Dans SIP, elle pouvait être une décision entièrement locale. Le serveur distant annonçait que le terminal appelé était alerté ; le poste appelant, ne recevant encore aucun média, fabriquait la tonalité familière. Quelques instants plus tard, un flux réseau pouvait prendre le relais. Pour l’oreille, la transition devait être invisible. Pour l’exploitation, elle séparait deux sources de preuve.

La RFC 3960, publiée en décembre 2004, décrivait les médias précoces, échangés après l’INVITE initial mais avant la réponse finale. Ils pouvaient transporter une tonalité, une annonce, l’attente d’un centre d’appels ou un dialogue interactif. Le texte refusait surtout de confondre progression de la signalisation et présence du média.

Sa politique illustrative pour un poste de type téléphonique comporte trois décisions. Sans réponse 180 Ringing, pas de sonnerie locale. Après 180, en l’absence de paquets entrants, le poste produit la tonalité. Si des paquets arrivent, il les joue et arrête la génération locale. La réponse 180 signifie que le correspondant est alerté ; elle doit être envoyée pour cet état, quelle que soit la situation de la session média précoce.

La signalisation ne pouvait pas trancher seule. Un serveur rudimentaire pouvait envoyer des médias sans réponse provisoire fiable. Un autre pouvait fournir une réponse SDP dans une réponse provisoire fiable uniquement pour satisfaire des préconditions, sans vouloir émettre immédiatement. La RFC 3262 fiabilisait les réponses provisoires avec RSeq, RAck et PRACK ; elle ne transformait pas un accusé de signalisation en reçu RTP. La RFC 3312 encadrait les préconditions de ressources ; leur satisfaction et la réception d’un son restaient deux événements.

Les chemins eux-mêmes divergeaient. La signalisation SIP passait souvent par plusieurs mandataires, tandis que le média cherchait le trajet le plus court. Des paquets pouvaient donc précéder la réponse qui les décrivait. À l’inverse, la signalisation pouvait arriver avant que la connectivité média soit prête. Un indicateur abstrait de média précoce n’aurait pas supprimé cette course. La RFC préférait une observation locale : indiquer la progression, puis céder aux paquets réellement reçus.

Même ces paquets ne prouvaient pas tout. Ils pouvaient ne contenir que du silence ou du bruit de confort. La RFC 3711 ajoutait à SRTP authentification, intégrité, protection contre la répétition et, au besoin, confidentialité. Une validation cryptographique ne garantissait toujours ni décodage, ni sortie haut-parleur, ni compréhension humaine. Il fallait distinguer 180, paramètres négociés, premier paquet, premier paquet authentifié et premier son utile.

La RFC 3264 définissait l’offre/réponse ; la RFC 3261 définissait les messages SIP qui la transportaient. Leur réussite attestait un accord de paramètres, pas un flux. Le client devait d’ailleurs être prêt à jouer des paquets avant 200 OK, faute de quoi les premiers mots du correspondant risquaient d’être coupés.

La bifurcation compliquait encore le jugement. Un INVITE pouvait produire plusieurs dialogues précoces et plusieurs flux. Mélanger les sons créait de la confusion ; la bande passante ne permettait pas toujours de tout recevoir. Dans le modèle passerelle, le client sélectionnait souvent une branche et rendait les autres muettes. Or la branche finalement acceptée par un 2xx pouvait être l’une des branches masquées. La réactiver tardivement provoquait une nouvelle coupure. Le flux présenté au début n’était donc pas nécessairement celui de la session retenue.

Le modèle serveur d’application séparait davantage les autorités. La RFC 3959 créait le type de disposition early-session et son option tag. Une offre précoce pouvait être rejetée ou coupée sans condamner la session régulière. Cette séparation améliorait le passage d’une branche à l’autre, sans dispenser le terminal de choisir quel flux précoce présenter.

Alert-Info ne décidait pas davantage du moment. Ce champ pouvait sélectionner un contenu alternatif si le client choisissait une sonnerie locale. Il ne donnait pas l’autorité de commencer à sonner.

La sécurité révélait une autre frontière. Une adresse de transport SDP ne s’authentifiait pas elle-même. Un adversaire pouvait apprendre ou deviner le port ; une offre malveillante pouvait faire viser une victime. La RFC évoquait la protection de la description, l’authentification du média et une preuve de consentement à recevoir avant un envoi volumineux. Elle signalait aussi une incitation tarifaire : si le média précoce était gratuit et le média régulier payant, un terminal malhonnête pouvait maintenir un échange bidirectionnel sans jamais envoyer 200 OK. Mais interdire tout média précoce bidirectionnel aurait cassé les serveurs vocaux légitimes.

L’histoire de la RFC 3960 n’est donc pas celle d’une tonalité standardisée. C’est celle d’un système qui préservait la différence entre être alerté, fabriquer un son, recevoir un flux et réussir un appel.

Le dossier RFC Editor et la recherche d’errata fixent la trace éditoriale. Les sources connexes sont les RFC 3261, 3262, 3264, 3959, 3312 et 3711.