Résumé

  • PRACK acquitte une réponse provisoire fiable déterminée. Le 2xx rendu à PRACK ne vaut pas acceptation de l’INVITE d’origine.
  • RSeq et RAck attachent l’accusé à un dialogue, une séquence et une méthode ; même si l’offre-réponse progresse avant la fin, ils ne prouvent ni la livraison du média ni le décrochage.

Le progrès n’était pas encore une donnée fiable

Dans le RFC 3261, un INVITE peut recevoir plusieurs réponses 1xx avant sa réponse finale. Les codes 101 à 199 indiquent la progression et peuvent créer un dialogue précoce. L’acceptation appartient au 2xx final ; les autres classes finales redirigent ou refusent. Or la spécification de base ne livre pas les réponses provisoires de façon fiable.

Cette lacune devient sensible lorsqu’une 1xx porte davantage qu’une indication d’interface. Dans l’interconnexion avec la téléphonie classique, elle peut soutenir une annonce, ouvrir un dialogue ou transporter une description de session. Sa perte ne décide pas nécessairement du sort de l’appel, mais elle peut retirer un état dont la suite dépend.

Le RFC 3262 introduit donc l’option 100rel et la méthode PRACK. Si l’INVITE annonce Supported: 100rel, le serveur peut envoyer de manière fiable une réponse provisoire autre que 100. S’il exige Require: 100rel, le serveur doit le faire ou refuser l’exigence d’extension. La réponse 100 Trying reste exclue, car elle est de proche en proche alors que la nouvelle fiabilité est de bout en bout.

Une référence composée, pas un simple numéro

La 1xx fiable contient Require: 100rel et un RSeq. Le premier numéro est choisi dans la plage prévue et l’espace de numérotation appartient à la transaction. Un même RSeq observé dans deux INVITE différents n’identifie donc pas le même état.

La réponse est retransmise avec un recul exponentiel à partir de T1. Un PRACK ne met fin aux répétitions que s’il appartient au même dialogue et si son RAck reprend le RSeq, le numéro CSeq et la méthode de la réponse acquittée. Le protocole lie ainsi l’accusé à trois coordonnées plutôt qu’à une impression générale de progression.

Quand la correspondance existe, le UAS répond 2xx au PRACK et retire la réponse de la liste des 1xx non acquittées. Sans correspondance, il répond 481. Le sujet grammatical importe : ce 2xx est la réponse au PRACK. L’INVITE conserve sa propre réponse finale, qui peut encore accepter, rediriger ou refuser.

PRACK joue un rôle semblable à ACK, mais n’est pas un ACK provisoire. C’est une requête non-INVITE ordinaire dans le dialogue, avec sa transaction fiable de proche en proche et sa propre réponse. Cette autonomie empêche précisément que le reçu d’un état intermédiaire soit confondu avec la décision finale.

La fiabilité impose un ordre

Les acquittements ne sont pas cumulatifs. Pour limiter la congestion, le RFC recommande de ne laisser qu’une réponse provisoire fiable en attente et interdit d’envoyer la deuxième avant que la première soit acquittée. Les RSeq suivants augmentent exactement d’une unité et ne bouclent pas.

Le client reconnaît une retransmission par le dialogue, le CSeq et le RSeq, puis l’écarte. Si un RSeq ultérieur arrive avant celui qui était attendu, il ne doit être ni traité ni acquitté ; il peut être conservé en attendant la pièce manquante. La fiabilité porte donc sur l’identité et l’ordre, pas seulement sur l’arrivée éventuelle d’un paquet.

Après 64*T1 sans PRACK correspondant, le serveur devrait rejeter la requête initiale avec un 5xx. Cette règle révèle le coût de l’extension : temporisateurs, mémoire des séquences, routage du dialogue et authentification deviennent autant d’états à préserver. Elle ne mesure pas la qualité des implémentations déployées.

Une négociation achevée dans un appel encore indécis

PRACK peut contenir un corps. Si l’INVITE porte une offre, une réponse provisoire fiable peut fournir la réponse. Si l’INVITE ne porte pas d’offre, la 1xx fiable peut en proposer une et PRACK doit y répondre. PRACK peut aussi porter une nouvelle offre, à laquelle son propre 2xx répond.

Les paramètres de session peuvent donc être établis avant la réponse finale à l’INVITE. Pour autant, l’invitation n’est pas acceptée. Si une réponse provisoire fiable non acquittée contient une description de session, le UAS doit retarder le 2xx final de l’INVITE jusqu’au PRACK. Cette dépendance protège l’échange offre-réponse ; elle ne transfère pas le pouvoir d’acceptation à PRACK.

Le RFC 6337 précise que la prise en charge de 100rel aux deux extrémités ne rend pas toutes les réponses provisoires fiables. Pour un INVITE contenant une offre, le premier SDP d’une réponse fiable sans échec constitue la véritable réponse ; un SDP antérieur dans une 1xx non fiable n’est qu’un aperçu.

Le RFC 3311 ajoute UPDATE pour modifier les paramètres dans les dialogues précoces ou confirmés. Il multiplie les chemins d’offre-réponse sans fusionner les transactions. INVITE, PRACK et UPDATE gardent leurs demandes, séquences et résultats propres.

Le média suit sa propre chronologie

Le RFC 3960 traite la tonalité, les annonces et d’autres médias précoces avant la réponse finale. La signalisation SIP et le média sont faiblement couplés ; ils peuvent emprunter des chemins différents et apparaître dans un ordre différent.

Un PRACK ne prouve donc pas que des paquets RTP sont arrivés, qu’une annonce a été entendue ou que l’appelé a décroché. Entendre l’annonce ne prouve pas davantage que le bon RSeq a reçu le bon RAck. Les deux chronologies doivent être rapprochées sans que l’une se substitue à la preuve de l’autre.

Le registre IANA répertorie PRACK, RAck, RSeq et 100rel avec le RFC 3262. Il atteste une attribution officielle, pas le déploiement, la conformité ni la part des appels concernés.

Enfin, une séquence correcte ne suffit pas à établir l’identité. Le RFC 3262 avertit qu’un attaquant pourrait injecter un PRACK pour arrêter la retransmission d’une information provisoire importante. PRACK devrait donc être authentifié comme les autres requêtes. Faire correspondre un état et faire confiance à son auteur restent deux contrôles distincts.

Sources