Résumé

  • Dans la RFC 2543, branch séparait surtout les copies créées par un proxy qui bifurquait ; la RFC 3261 en fit un identifiant obligatoire, unique dans l’espace et le temps.
  • z9hG4bK signale la nouvelle règle de construction. Le serveur peut appliquer l’appariement compact moderne ou, en son absence, conserver la procédure multichamp héritée.
  • Une retransmission reprend la branche, une nouvelle tentative en reçoit une autre. CANCEL et l’ACK d’un échec la réutilisent volontairement, sans confondre leurs résultats.

Avant le cookie, la branche ne séparait qu’une bifurcation

Un appel SIP n’est pas une conversation directe entre deux téléphones. Une requête peut traverser plusieurs proxies ; chacun empile un champ Via qui indique le retour de la réponse. Un proxy avec état peut aussi essayer plusieurs destinations et doit savoir de quelle tentative revient chaque réponse.

La RFC 2543, publiée en 1999, utilisait déjà le paramètre branch. Un proxy qui dupliquait une requête devait donner une branche différente à chaque copie isomorphe. Sur un trajet unique, le paramètre restait facultatif. Son unicité ne dépassait pas l’ensemble local des copies.

Le serveur ne pouvait donc pas traiter n’importe quelle branche comme un identifiant universel de transaction. La correspondance mobilisait aussi To, From, Call-ID, CSeq et le premier Via. La valeur aidait un proxy à ranger ses réponses ; elle ne déclarait pas encore une discipline commune à tous les émetteurs.

Un préfixe visible a choisi la loi applicable

La RFC 3261 a changé ce contrat en 2002. Toute requête créée par un client devait porter un Via supérieur avec une branche. Sauf exceptions expressément définies, cette valeur devait être unique dans l’espace et dans le temps.

Mais comment un récepteur pouvait-il savoir qu’une valeur avait été créée sous la nouvelle règle plutôt que sous l’ancienne ? La réponse tient dans sept caractères imposés : z9hG4bK. Ils ont été choisis pour qu’une implémentation RFC 2543 ait très peu de chances de les avoir produits par accident.

Le préfixe ne décrit ni un fournisseur, ni une date, ni un utilisateur. Il sélectionne une grammaire. Présent, il autorise le récepteur à compter sur la promesse RFC 3261 ; absent, il interdit de l’inventer. La compatibilité devient une décision locale et vérifiable, pas une supposition sur l’âge du voisin.

La transaction est devenue reconnaissable localement

Avec le cookie, une requête correspond à une transaction serveur lorsque concordent la branche du premier Via, son sent-by et la méthode, avec la règle particulière de l’ACK. sent-by reste nécessaire : deux clients peuvent réutiliser la même valeur par erreur ou par malveillance.

Sans cookie, la procédure héritée compare Request-URI, tags, Call-ID, CSeq et Via. Les deux générations peuvent donc cohabiter. Le logiciel ne transforme pas silencieusement une ancienne étiquette de fork en preuve qu’elle n’a jamais promise.

Pour une réponse, la branche supérieure et la méthode du CSeq identifient la transaction cliente. La méthode compte parce que CANCEL possède sa propre transaction tout en reprenant la branche de la requête visée.

Les scénarios de la RFC 3665 montrent le mécanisme en mouvement : chaque proxy ajoute sa couche Via, puis la retire au retour. La branche appartient à la relation transactionnelle entre deux voisins. Elle ne baptise ni l’appel entier ni la personne appelée.

Répéter exige la même branche ; réessayer en exige une nouvelle

Une nouvelle destination constitue une nouvelle tentative de proxy et reçoit une nouvelle branche. Une copie retransmise de la même tentative doit conserver l’ancienne. Sinon, le serveur l’exécuterait comme une opération nouvelle au lieu de retrouver son état et, si nécessaire, de renvoyer la réponse mémorisée.

Cette exigence est délicate pour un proxy sans état. Il ne possède aucun tableau lui permettant de reconnaître la deuxième arrivée. Il ne peut donc pas tirer un nombre neuf au hasard à chaque paquet. La RFC 3261 lui demande de dériver la partie stable de la branche de champs invariants pendant la retransmission et d’une configuration elle aussi stable.

La détection de boucle ajoute une autre nuance. Une requête revenue sans changement de décision peut être une boucle ; revenue avec une URI ou des paramètres de routage transformés, elle peut former une spirale légitime. La branche peut refléter les entrées qui font réellement varier le traitement. Elle compresse une preuve, mais seulement après que l’implémentation a défini ce qui compte.

CANCEL partage la référence, pas le destin

Pour atteindre la bonne opération en attente, CANCEL recopie URI, Call-ID, tags, numéro CSeq, Via et branche. Sa méthode CSeq devient toutefois CANCEL. Ce détail permet au serveur de localiser la requête cible puis de traiter l’annulation comme une transaction autonome.

Un 200 à CANCEL confirme le traitement de CANCEL. L’INVITE initial doit encore recevoir sa propre réponse finale, souvent 487 si l’annulation arrive à temps. Une réponse finale déjà produite peut également avoir gagné la course. La RFC 3261 a précisément séparé ces deux fins que la RFC 2543 mêlait. Même identifiant de corrélation ne signifie pas même engagement.

L’ACK se divise au seuil du succès

Après une réponse finale non-2xx, l’ACK reste dans la transaction INVITE. Il reprend le Via et la branche, change la méthode et se fait absorber par la machine transactionnelle du chemin qui a transporté l’échec.

Après un 2xx, plusieurs destinations issues d’un fork peuvent avoir accepté. Toutes les réponses réussies doivent atteindre le client. L’ACK est donc produit par le cœur du terminal et circule de bout en bout hors de la transaction INVITE hop-by-hop, avec un nouveau Via construit pour cet échange. Le partage ou le renouvellement de la branche suit la responsabilité de retransmission, pas une préférence esthétique.

Les réparations ultérieures ont changé la durée, pas l’identité

Une bonne clé ne garantit pas une bonne durée de conservation de l’état. La RFC 4320 a corrigé des comportements de réponse et de délai des transactions non-INVITE. La RFC 6026 a ajouté l’état Accepted et Timer L afin qu’un serveur reconnaisse encore les retransmissions d’un INVITE après l’envoi d’un 2xx.

Cette dernière conserve même un traitement particulier pour l’ACK ancien dont la branche ne porte pas le cookie. L’identité de la transaction et sa durée de vie restent deux questions séparées. La RFC 5359 offre des exemples de services utilisant la convention moderne ; elle documente une grammaire, pas le taux mondial de conformité.

Ce que le cookie n’a jamais prouvé

N’importe qui peut écrire z9hG4bK. Le préfixe n’authentifie pas l’émetteur, ne chiffre rien, n’autorise pas un appel et ne garantit même pas que la suite est réellement unique. Un appariement réussi prouve seulement que le message rejoint l’état transactionnel local selon les règles observées.

Dialogues, routes, identité d’utilisateur, autorisation, négociation média et qualité d’appel disposent d’autres objets et d’autres preuves. La réussite historique est volontairement mince : l’émetteur indique la règle suivie, le récepteur la vérifie à sa frontière, et aucun des deux ne transforme cette indication en pouvoir général.

Sources et limites des preuves

Le corpus fermé réunit la RFC 2543, la RFC 3261, la RFC 3665, la RFC 4320, la RFC 5359 et la RFC 6026. Elles établissent règles, histoire, exemples et corrections ; elles ne mesurent ni déploiement actuel, ni conformité d’un produit, ni qualité réelle des appels.